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

This article is to share with you about the impact of locks on the performance of Disruptor, 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.

Disruptor is a high-performance queue developed by the British foreign exchange trading company LMAX. The original purpose of the research and development is to solve the delay problem of memory queues (in the performance test, it is found to be in the same order of magnitude as the Icano operation). The single thread system developed based on Disruptor can support 6 million orders per second. After the speech at QCon in 2010, it won the attention of the industry. In 2011, enterprise application software expert Martin Fowler specially wrote a long article introduction. In the same year, it also won the Oracle's official Duke Award.

At present, many well-known projects, including Apache Storm, Camel, Log4j 2, have applied Disruptor to achieve high performance. It also has many applications in Meituan's technical team, and some project architectures draw lessons from its design mechanism. This paper analyzes the implementation principle of Disruptor from the point of view of actual combat.

In particular, the queues mentioned here are memory queues within the system, not distributed queues such as Kafka. In addition, the Disruptor features described in this article are limited to 3.3.4.

Before introducing Disruptor, let's take a look at what's wrong with the commonly used thread-safe built-in queues. The built-in queues for Java are shown in the following table.

Queue bounded lock data structure ArrayBlockingQueuebounded locked arraylistLinkedBlockingQueueoptionally-bounded locked linkedlistConcurrentLinkedQueueunbounded unlocked linkedlistLinkedTransferQueueunbounded unlocked linkedlistPriorityBlockingQueueunbounded locked heapDelayQueueunbounded locked heap

The bottom layer of a queue is generally divided into three types: array, linked list, and heap. In general, the purpose of heap is to implement queues with priority characteristics, which is not considered for the time being.

From the perspective of array and linked list data structures, the typical queue based on array thread safety is ArrayBlockingQueue, which ensures thread safety mainly by locking. Thread-safe queues based on linked lists are divided into two categories: LinkedBlockingQueue and ConcurrentLinkedQueue. The former also realizes thread safety by locking, while the latter and the LinkedTransferQueue in the above table are realized by the unlocked atomic variable compare and swap (hereinafter referred to as "CAS").

Queues implemented without locking are unbounded (there is no guarantee that the length of the queue is within a certain range), while locking enables bounded queues. In systems with high stability requirements, in order to prevent producers from overrunning memory, we can only choose bounded queues; at the same time, in order to reduce the impact of Java garbage collection on system performance, we will try to choose data structures in array/heap format. In this way, the only queue that meets the criteria is ArrayBlockingQueue.

In the actual use of ArrayBlockingQueue, there will be serious performance problems such as locking and pseudo-sharing, so let's analyze it below.

Add lock

In the real programming process, locking usually seriously affects performance. The thread is suspended because it cannot compete for the lock, and when the lock is released, the thread is restored again, which is expensive and usually has a long interruption, because when a thread is waiting for the lock, it can't do anything else. If a thread is delayed while holding a lock, such as a page fault, scheduling delay, or something like that, none of the threads that need the lock can execute. If the blocked thread has a higher priority and the thread that holds the lock has a lower priority, a priority inversion occurs.

Disruptor's paper describes an experiment:

The test program calls a function that increments itself 500 million times against a 64-bit counter.

Machine environment: 2.4G 6 cores

Operation: 64-bit counter adds up to 500 million times

MethodTime (ms) Single thread300Single thread with CAS5700Single thread with lock10000Single thread with volatile write4700Two threads with CAS30000Two threads with lock224000

CAS operation is one order of magnitude slower than that of single thread without lock; in the case of lock and multithread concurrency, the speed is three orders of magnitude slower than that of single thread without lock. It can be seen that the speed of unlocked is the fastest.

In the case of single thread, the performance of unlocked > the performance of CAS operation > the performance of locked.

In the case of multithreading, CAS or locks must be used in order to ensure thread safety, in which case the performance of CAS exceeds the performance of locks, the former is about eight times that of the latter.

The above is the impact of locks on performance in Disruptor, and 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.