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

What are the waiting strategies in Disruptor-06? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

/ /. / / Construct the Disruptor with a SingleProducerSequencer Disruptor disruptor = new Disruptor (factory, bufferSize, DaemonThreadFactory.INSTANCE, ProducerType.SINGLE, new BlockingWaitStrategy ()); /.

BlockingWaitStrategy

The default wait strategy used by the Disruptor is the BlockingWaitStrategy. Internally the BlockingWaitStrategy uses a typical lock and condition variable to handle thread wake-up. The BlockingWaitStrategy is the slowest of the available wait strategies, but is the most conservative with the respect to CPU usage and will give the most consistent behaviour across the widest variety of deployment options. However, again knowledge of the deployed system can allow for additional performance.

BlockingWaitStrategy uses a typical lock and condition variable to handle thread wake-up. BlockingWaitStrategy is the slowest of the available wait policies, but it is the most conservative in terms of CPU usage, providing the most consistent behavior across a variety of deployment environments. It is understood that deployed systems still bring additional performance improvements. SleepingWaitStrategy

Like the BlockingWaitStrategy the SleepingWaitStrategy it attempts to be conservative with CPU usage, by using a simple busy wait loop, but uses a call to LockSupport.parkNanos (1) in the middle of the loop. On a typical Linux system this will pause the thread for around 60 μ s. However it has the benefit that the producing thread does not need to take any action other increment the appropriate counter and does not require the cost of signalling a condition variable. However, the mean latency of moving the event between the producer and consumer threads will be higher. It works best in situations where low latency is not required, but a low impact on the producing thread is desired. A common use case is for asynchronous logging.

Like BlockingWaitStrategy, SleepingWaitStrategy tries to be conservative in terms of CPU usage by using a simple busy wait loop, but uses a LockSupport.parkNanos (1) call in the middle of the loop. In a typical Linux system, the thread will be suspended for about 60 μ s. However, its advantage is that the generating thread does not need to take any other action to increase the appropriate counter, nor does it require the cost of sending conditional variables. However, the average latency of moving events between producer and consumer threads is higher. It works best when you don't need low latency, but you want to have a low impact on the build thread. A common use case is asynchronous logging. YieldingWaitStrategy

The YieldingWaitStrategy is one of 2 Wait Strategies that can be use in low latency systems, where there is the option to burn CPU cycles with the goal of improving latency. The YieldingWaitStrategy will busy spin waiting for the sequence to increment to the appropriate value. Inside the body of the loop Thread.yield () will be called allowing other queued threads to run. This is the recommended wait strategy when need very high performance and the number of Event Handler threads is less than the total number of logical cores, e.g. You have hyper-threading enabled.

YieldingWaitStrategy is one of two waiting strategies that can be used in low-latency systems. In low-latency systems, you can choose to consume CPU cycles to improve latency. YieldingWaitStrategy will be busy rotating, waiting for the sequence to increase to the appropriate value. Call Thread.yield () inside the body of the loop to allow other queued threads to run. This is the recommended waiting strategy when very high performance and event handling are required and the number of program threads is less than the total number of logical kernels, such as enabling hyperthreading. BusySpinWaitStrategy

The BusySpinWaitStrategy is the highest performing WaitStrategy, but puts the highest constraints on the deployment environment. This wait strategy should only be used if the number of Event Handler threads is smaller than the number of physical cores on the box. E.g. Hyper-threading should be disabled.

BusySpinWaitStrategy is the most efficient wait policy, but it also has the highest restrictions on the deployment environment. This wait strategy should be used only if the number of event handler threads is less than the number of physical cores on the machine. For example, hyperthreading should be disabled. After reading the above, have you mastered the methods of waiting strategy in Disruptor-06? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.