RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock
brian.burkhalter at oracle.com
Wed Jan 31 03:04:15 UTC 2018
On Jan 30, 2018, at 12:58 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> The proposed fix is:
> I think it would be simpler if FileChannel maintained a set of the valid locks obtained via the channel, the the unlock can remove the lock from the set.
I don’t see how to do this. The FileLock already holds a reference to the Channel and if the converse were to obtain there would be circular references and things blocked from being collected. I did however come up with a simpler change which passes the new test:
More comprehensive testing would need to be done if this looks better.
On Jan 30, 2018, at 2:16 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> Should fileKey be made final (AFAICS the field
> is never mutated) and should isLockReleased
> be volatile (appears that it could be mutated/read
> from different threads)?
Fixed in the above webrev.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nio-dev