On Sat, 9 Oct 2021 19:02:17 GMT, XenoAmess <d...@openjdk.java.net> wrote:
>>> in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, >>> it might make this.skipBuffer to a byte[6] in thread A, and thus cause a >>> IndexOutofBoundException in Thread A. >> >> No, it won't. The later `skipBuffer` references are made to the local >> variable; so even though the `new byte[6]` may replace the cached `new >> byte[10]` skip buffer in instance field, in thread A, it is still using the >> old `new byte[10]` which is stored in the local variable/stack, and >> everything just proceeds fine (only shortcoming is that the 10-length skip >> buffer is wasted and recycled) > >> > in extream situation, when doing this.skipBuffer = skipBuffer in Thread B, >> > it might make this.skipBuffer to a byte[6] in thread A, and thus cause a >> > IndexOutofBoundException in Thread A. >> >> No, it won't. The later `skipBuffer` references are made to the local >> variable; so even though the `new byte[6]` may replace the cached `new >> byte[10]` skip buffer in instance field, in thread A, it is still using the >> old `new byte[10]` which is stored in the local variable/stack, and >> everything just proceeds fine (only shortcoming is that the 10-length skip >> buffer is wasted and recycled) > > you are correct. I forgot you use same name local variable hiding the field > variable, so the later skipBuffer passed to read() is local variable. > > (sigh) I feel like super stupid when facing multithread programming. Isn't it the case that the length of the global `skipBuffer` is non-decreasing? Thus skipping 6 bytes after skipping 10 will not result in a new buffer allocation. Even so, it does appear that prior buffer allocations could be "lost" due to concurrent use of `skip` resulting in a "minor" memory leak in the heap. ------------- PR: https://git.openjdk.java.net/jdk/pull/5872
