I recently used Alibaba's Dubbo [BaiduProgramAfter a lot of optimization work, the jvisualvm in JDK did a lot of work in this process, but it also gave me some misunderstanding.
Let's talk about its merits:
First, you can help me monitor the number of threads and promptly discover threads that are not normally terminated. Because Dubbo is configured with a 800 thread pool, the number of daemon threads in my current active thread is 826, and the total number minus the number of threads in the 800 thread pool, Dubbo occupies 26 daemon threads, most of the threads are generated in my program.
Second, you can monitor CPU usage.
Third: monitor the memory usage of the heap.
Fourth: monitor the total number of classes loaded.
No need to modify the original JavaSource codeYou only need to perform simple configuration. For detailed configuration, see [http://blog.csdn.net/ssergsw/article/details/9933227]
Let's talk about its problems:
After monitoring is added, the heap memory usage is significantly different from normal usage:
Three minutes after monitoring is started:
The following figure shows 10 minutes after monitoring:
By comparing the two figures, we can see that when the monitoring is not used, the heap memory usage is balanced. After the monitoring is used, the heap memory increases rapidly, and then GC is performed in about 5 minutes, then it gradually increases, so we suggest you pay more attention to the loading of threads and classes when using monitoring. In addition, do not use tool monitoring programs for a long time!