Shulou(Shulou.com)06/02 Report--

This article is to share with you about the problems that you need to pay attention to when using Disruptor in Java. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Find processes that take up more than 100% of CPU time

First, check the server status with the top command on the server, and find that an application takes up more than 100% of the CPU, as shown in the figure:

I checked against the process number and found that it was one of my Java game background services, and one of the CPU was almost full, so I continued to investigate what code caused the situation.

Show all the threads of this process with top-Hp 27538, sort by CPU elapsed time, and see this result:

27658 threads take up almost all the CPU time, and it always is, so check out the details of the process.

Use the jstack pid > pid.log command to output a snapshot of the process to a file and download it.

After converting 27658 to hexadecimal 0x6c0a, query it in the thread snapshot (because the thread ID in the thread snapshot is stored in hexadecimal, it needs to be converted):

"disruptor-0" # 27 prio=5 os_prio=0 tid=0x00007fa100c58000 nid=0x6c0a runnable [0x00007fa0ae080000]

Java.lang.Thread.State: RUNNABLE

At com.lmax.disruptor.BusySpinWaitStrategy.waitFor (BusySpinWaitStrategy.java:39)

At com.lmax.disruptor.ProcessingSequenceBarrier.waitFor (ProcessingSequenceBarrier.java:56)

At com.lmax.disruptor.BatchEventProcessor.processEvents (BatchEventProcessor.java:159)

At com.lmax.disruptor.BatchEventProcessor.run (BatchEventProcessor.java:125)

At java.lang.Thread.run (Thread.java:748)

This is a stack of Disruptor, and snapshots can be uploaded to a dedicated analysis platform in order to see the state information of threads more intuitively.

(the blogger himself is also a novice in the process snapshot analysis. If you have any suggestions or comments, please feel free to leave a message below. )

Analyze why Disruptor takes up the entire CPU

According to the analysis of the above snapshot, it is actually caused by threads related to the waiting policy of Disruptor. Check the BusySpinWaitStrategy class and find that there are relevant instructions:

* This strategy will use CPU resource to avoid syscalls which can introduce latency jitter. It is best

* used when threads can be bound to specific CPU cores.

Now I finally know, because this strategy is to bind a thread to a CPU core, and naturally its CPU takes more than 100% of the time.

These are the problems that need to be paid attention to when using Disruptor in Java. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.