[9] RFR 8166253: (ch) FileLock object can get GC'd and result in unexpected release of file lock

Alan Bateman 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:
> http://cr.openjdk.java.net/~bpb/8166253/webrev.05/ 
> <http://cr.openjdk.java.net/%7Ebpb/8166253/webrev.05/>
> 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 mailing list