All modifications of Buffer are done with the buffer lock acquired. However, in some scenarios, it is known that only a single thread accesses a given buffer, e.g. when handling a regular message / message batch in NAKACK2 and UNICAST3:

• The message processing policy is MaxOneThreadPerSender
• The BatchHandlerLoop adds a message batch to a buffer
• Then it calls Buffer.removeMany()
• These 2 operations can be done without the need to acquire/release a lock
• This path is executed on almost every regular message/batch reception, and therefore this optimization might be useful.

Check if there's another path in which OOB messages/batches can be added to the same buffer concurrently This would invalidate this scenario!

JMH ([1]) shows that an uncontended lock and unlock costs ~1500ns!

[1] https://github.com/belaban/JmhTests/blob/master/src/main/java/org/jgroups/MyBenchmark.java#L126