RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock
Alan.Bateman at oracle.com
Fri Feb 2 17:56:59 UTC 2018
On 01/02/2018 01:56, Brian Burkhalter wrote:
> I created and tested an updated version which maintains a set of hard
> references to the locks for the channel inside the FileLockTable itself:
> Given that the set is always accessed inside a block synchronized on
> the list corresponding to the FileKey in the global
> FileKey-to-FileLockReference table, I think the Set could probably be
> initialized at line 124 to a simple HashSet instead of a
> ConcurrentHashMap.KeySetView<FileLock,Boolean> but I wanted to solicit
> comments on that point.
Yes, it can be a HashSet. Also in the case of removeAll then you can
invoke locks.clear(). In the case of replace then I think it would be
more understandable if the remove+add are together.
More information about the nio-dev