InputStream/OutputStream concurrency guarantees

[Viktor Klang]

Also, since there aren't any consistency effects in place, it is not 
deterministic which changes made by the writer would be seen by the 
reader/copier.

On 2025-10-27 18:35, Pavel Rappo wrote:
> In the absence of "frozen arrays" -- which I'm not even sure could be
> useful here -- we cannot guarantee that a shared byte[] passed to
> OutputStream.write is not meddled with from outside, no matter if
> synchronization or defensive copy is used. To clarify the latter
> point: the array may be changed while it's being copied, which is no
> different from it being changed while it is being written from.
>
> If someone is flipping bytes while OutputStream.write has not yet
> returned, then I reckon it's a programming bug or an adversarial
> attack, which was probably enabled by such bug. Not sure if there was
> any other answer expected.
>
> -Pavel
>
> On Mon, Oct 27, 2025 at 5:02 PM Alan Bateman <alan.bateman at oracle.com> wrote:
>>
>>
>> On 27/10/2025 11:47, Pavel Rappo wrote:
>>
>> The specification of the read/write methods, their classes, and the
>> package is silent on multithreading. In which case you should always
>> assume that the methods are **not** thread-safe.
>>
>> Right, although there are some APIs that do specify that input or output streams are safe for used by concurrent threads, e.g. the input/output streams returned by the Channels class that support interop between channels and input/output streams.
>>
>> Another more subtle aspect to the topic is async close. With many input/output streams it doesn't make any sense to attempt to use them from concurrent threads but async close when there is a blocker read/writer is something that has to be supported in some cases.
>>
>> In any access, I read Florian's mail as asking something else. I read the mail as concurrent access to the byte[], e.g. someone flipping bytes while someone is calling write.
>>
>> -Alan

-- 
Cheers,
√


Viktor Klang
Software Architect, Java Platform Group
Oracle