4 ms·
> In general arrays and concurrency doesn't mix very well in Java, and is something I'd avoid mixing on principle. Sound sensible. I think what you've said is
by orra 3y ago
> In general arrays and concurrency doesn't mix very well in Java, and is something I'd avoid mixing on principle.
Sound sensible. I think what you've said is any semi-malicious code can give you a primitive array, then modify it from under you in another thread. That's not completely surprising but the clincher is, you can't even take a defensive copy.
- marginalia_nu 3y agoWell I mean there are things you can do prevent the JVM from this particular optimization. But you need to use the right tools to tell Java to expect spooky action at a distance, and arraycopy just isn't sufficient. This would probably do byte[] b; // A synchronized (a) { b = System.arraycopy(a); } // B Here A happens-before B, and you can assume a read fence at the start of synchronized block and a store fence at end of it, so consumers of b should get a consistent view of the array, and the synchronized block tells Java that you expect a to be modified by another thread so it can't assume it stays the same throughout the execution; and elision of the arraycopy isn't possible; so while the array may be in a weird state, it will at least stay consistent throughout the execution.