java.nio.ByteBuffer.slice() 线程行为？

Question

I understand that java.nio.ByteBuffer itself is not thread safe. However, if you obtain a shared, derived ByteBuffer via slice(), will you be able to access the contents of the underlying buffer concurrently in multiple threads, through different slice'd buffers? I cannot find anything about this in the API spec... If this behaviour isn't standardised, do you know how it's implemented in the most common VMs?

Answer 1

Basically, if something isn't documented to be thread-safe, assume it's not; if something is explicitly documented as not being thread-safe, never assume anything closely related is thread-safe unless documented otherwise.

---

As you mention, buffers are not thread-safe. This is documented by Buffer :

Buffers are not safe for use by multiple concurrent threads. If a buffer is to be used by more than one thread then access to the buffer should be controlled by appropriate synchronization.

And the documentation of ByteBuffer , which extends Buffer , does not contradict the above.

Here's what the documentation of ByteBuffer#slice() says:

Creates a new byte buffer whose content is a shared subsequence [emphasis added] of this buffer's content.

The content of the new buffer will start at this buffer's current position. Changes to this buffer's content will be visible in the new buffer, and vice versa; the two buffers' position, limit, and mark values will be independent. [emphasis added]

The new buffer's position will be zero, its capacity and its limit will be the number of bytes remaining in this buffer, its mark will be undefined, and its byte order will be BIG_ENDIAN . The new buffer will be direct if, and only if, this buffer is direct, and it will be read-only if, and only if, this buffer is read-only.

Other similar methods, such as #slice(int,int) and #alignedSlice(int) , document similar behavior.

As you can see, the contents of the buffer instances is shared. The documentation does not mention anything about adding thread-safety in this situation, thus we can confidently assume the general thread-safety of buffers applies—that is, there is no thread-safety. If any buffer sharing the same subsequence of contents is written to, all the other buffers will be affected. In a concurrent context, without proper external synchronization, this means potential race-conditions.

I'm not positive how this applies to reading from and writing to distinct (ie non-overlapping) subsequences. I assume whatever behavior applies to arrays applies in this case. Of course, that doesn't take into account direct buffers.

That all being said, there are some subtleties to this. As documented, each buffer will have independent position, limit, and mark values. A consequence of this is that each buffer can be read by a separate thread. However, this is a one-to-one mapping between buffer and thread (unless you add external synchronization) ¹ . This is because the position and mark values can be modified just by reading a buffer (at least, that's the case with relative read operations ¹ ) and rewinding.

---

^{1. I believe multiple threads could read from the same buffer instance without synchronization if, and only if, they all use the absolute read operations and don't use marks. In other words, as long as none of the threads modify the "meta-state" of the buffer.}