RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

[Peter Levart]

On 05/12/2015 10:49 PM, Mandy Chung wrote:
>> But I think it should be pretty safe to make the java.util.Properties 
>> object override all Hashtable methods and delegate to internal CMH so 
>> that:
>> - all modification methods + all bulk read methods such as 
>> (keySet().toArray, values.toArray) are made synchronized again
>> - individual entry read methods (get, containsKey, ...) are not 
>> synchronized.
>>
>> This way we get the benefits of non-synchronized read access but the 
>> change is hardly observable. In particular since external 
>> synchronization on the Properties object makes guarded code atomic 
>> like it is now and individual entry read accesses are almost 
>> equivalent whether they are synchronized or not and I would be 
>> surprised if any code using Properties for the purpose they were 
>> designed for worked any differently.
>
> I agree that making read-only methods not synchronized while keeping 
> any method with write-access with synchronized is pretty safe change 
> and low compatibility risk.  On the other hand, would most of the 
> overrridden methods be synchronized then?

Yes, and that doesn't seem to be a problem. Setting properties is not 
very frequent operation and is usually quite localized. Reading 
properties is, on the other hand, a very frequent operation dispersed 
throughout the code (almost like logging) and therefore very prone to 
deadlocks like the one in this issue. I think that by having an 
unsynchronized get(Property), most problems with Properties will be 
solved - deadlock and performance (scalability) related.

Regards, Peter

>
> Mandy