HashedWheelTimer cost too many CPU times

[michaelmao999]

Describe the bug

When launching BenchmarkServer, only one instnce cost 39-67% CPU times.
After launching 3 instances, it cost 100% CPU times.

Environment

• SOFAJRaft version: lastest version
• JVM version (e.g. java -version): JDK 1.8.202
• OS version (e.g. uname -a): Windows 10
• Maven version: 3.6.0
• IDE version: IDEA 2018.3.5
• CPU (Intel i5-6300HQ 4 cores)

[kenro]

I also encountered the same problem，where I just ran a example project-CounterServer。And I found HashedWheelTimer cost too much cpu resource。

[killme2008]

It looks that a bug in HashedWheelTimer on windows platform, we will look into it, thanks.

[fengjiachun]

https://stackoverflow.com/questions/10536798/java-netty-nio-connect-generates-an-excessive-amount-of-interrupts-on-windows-20

Caused by windows generating an interrupt when java called Thread.sleep() and is solved by not sleeping if the time is lower than 10 ms， and this may cause high cpu

https://github.com/netty/netty/blob/21b7e29ea7c211bb2b889bae3a0c6c5d9f60fb01/common/src/main/java/io/netty/util/HashedWheelTimer.java#L572

[michaelmao999]

Currently, VoteTimer, ElectionTimer, StepDownTimer and SnapshotTimer use HashedWheelTimer class, but it seems that JDK ScheduledExecutorService API is enough, there is no special requirement to use HashedWheelTimer

[fengjiachun]

Maybe we should implement #269 and replace the HWT @SteNicholas

[michaelmao999]

I fixed this sleepTime issue on windows, for detail, please access the following URL,
michaelmao999@0579e55

[fengjiachun]

@michaelmao999 I don't have a windows, but I think Thread.sleep(1) will cause an interrupt，and this may cause high cpu. Have you observed that the above problem no longer occurs?

[fengjiachun]

if (Platform.isWindows() && sleepTimesMs > 10) {
    sleepTimeMs = sleepTimeMs / 10 * 10;
}

Maybe the above code is better? Avoid calling Thread.sleep() multiple times

[michaelmao999]

Sounds good.

[fengjiachun]

@michaelmao999 can you send a PR for this?