log4j2 AsyncLogger uses RingBuffer (Disruptor) which is lock-free
https://github.com/LMAX-Exchange/disruptor/wiki/Blogs-And-Ar...
In ARM and Lock-Free ProgrammingLMAX-Exchange
disruptor
Java2013–2025
LMAX-Exchange / disruptor
disruptor
High Performance Inter-Thread Messaging Library
26Distinct people
26Mentions
0Explicit recommenders
18.5KGitHub stars
What to know before exploring
What it is
High Performance Inter-Thread Messaging Library
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year26 dated mentions
Observed mentions: 2013-01-08 01:58:48 UTC to 2025-12-16 14:25:08 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
LMAX Disruptor
A High Performance Inter-Thread Messaging Library
Maintainer
LMAX Development Team
Support
Open a ticket in GitHub issue tracker
Google Group
Documentation
Overview
User Guide
API Documentation
Developer Guide
FAQ
Read the full README on GitHubWhat Hacker News says
6 sourcesin LMAX-disruptor's case, they have no runtime dependencies: https://github.com/LMAX-Exchange/disruptor/blob/master/build...
In Game Programming Patterns: Event Queue (2014)If anyone is curious, one of the fastest multi-threaded queue implementations out there is the LMAX Disruptor.
https://github.com/LMAX-Exchange/disruptor
https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
I've started using a variant of this in my .NET Core projects and have found the performance to be astonishing.
In Game Programming Patterns: Event Queue (2014)There is an open-source project by LMAX (a forex trading company) called Disruptor[1] that squeezes as much as possible out of the JVM. It's awesome. I ported it to C++ years ago when I wanted to learn about low-latency techniques. However, if you look at the code they need to actually break out of the JVM's safety net to get the performance they need[2]. I couldn't help but ask myself why they didn't just use C++, and when asked one of the devs did admit that their own C++ ports had an approx 10% performance increase (although this was ~7 years ago maybe)
Rust is certainly interesting and it's on my radar. I wonder though, when it comes to having it in use in anger if its guarantees turn out to be over sold, just like the JVM's safety claims were. Time will tell.
Edit: I tend to focus on comapring against the JVM because pretty much any
Read the rest
framework you use on The Cloud is JVM based. I'm of the opinion that there are cost savings to be had if these were ported to more appropriate languages, hence the Cassandra vs Scylla comparison. The money saved was 'noticeable'.
[1] https://github.com/LMAX-Exchange/disruptor
[2] http://mishadoff.com/blog/java-magic-part-4-sun-dot-misc-dot...
I'm not entirely clear on the use case, but Disruptor by LMAX Exchange is for the JVM and seems very concerned with latency. (https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...)
In Jane Street and the OCaml Compiler (2018) [video]Is it?
I'd be interested to see benchmarks showing that spinlocks with CAS have similar throughput to a ringbuffer with atomic increment.
Note that with the ringbuffer approach, each reader can process many slots at once, since you're taking the minimum of all published slot numbers. If you last processed slot 3, and the minimum publish count is 9, you can process slot 4 through 9 without doing any atomic operations at all. The design guarantees safety with no extra work.
It's not a minor trick; it's one of the main reasons throughput is orders of magnitude higher.
Benchmarks: https://github.com/LMAX-Exchange/disruptor/wiki/Performance-...
Beyond that, the ringbuffer approach also solves the problem you'll always run into: if you use a queue, you have to decide the max size of the queue. It's very hard to use all available resources witho
Read the rest
ut allocating too much and swapping to disk, which murders performance. Real systems with queues have memory usage patterns that tend to fluctuate by tens of GB, whereas a fixed-size ringbuffer avoids the problem.