When the tool is running, the CPU consumes too much analysis and positioning

Previously, a device file collection tool was developed using Java Swing. Supports multiple devices to be collected at the same time, using one thread per device. At the same time collect more than one device information, found that the CPU occupancy rate actually reached 97%, and high. Obviously, such performance is intolerable.

We know that with the tools JVISUALVM the JDK, you can see the execution of each thread, but it is impossible to analyze the CPU usage of each thread. Because the tool is running on a Windows system, there is no way to analyze the CPU usage of a thread like Linux under the command. And Microsoft's Process Explorer tool can solve this problem. With this powerful analysis tool, we finally found a thread that consumes nearly 20% of the CPU. In conjunction with the thread information in the JVISUALVM, this thread is found to be sessionmonitor, which is used to monitor the status of each SSH connection. This means that each collection thread corresponds to an SSH connection, and it corresponds to a sessionmonitor thread. So it is because of the presence of multiple sessionmonitor that the CPU is occupied very high.

At this point, you need to analyze separately why the Sessionmonitor CPU is taking up too much. Find the corresponding source code, found that there is a loop in the Sessionmonitor, the loop inside constantly to occupy and release IO resources. The most deadly is that this cycle is very violent and does not use sleep to "sleep for a while", so the CPU is too high to be understood. After adding sleep in this cycle, performance has been significantly increased from 97% to less than 30%.

When the tool is running, the CPU consumes too much analysis and positioning