I’m currently diving in the implementation of java 11 Properties class. In java 11 source code, Properties class stores its data in a ConcurrentHashMap field called ‘map’. When you call the method setProperty of Properties, under the hood it makes a put method call of its internal ConcurrentHashMap. I understand that ConcurrentHashMap is a thread-safe collection, so i don’t really get why the setProperty method has to be synchronized if ConcurrentHashMap already is. The synchronization of setProperty method isn’t killing the point of using a ConcurrentHashMap. By this i mean that users of Properties class will have to wait to lock for setProperty method that already uses a concurrent collection with its own synchronization.

public class Properties extends Hashtable<Object,Object> {
/**
 * use serialVersionUID from JDK 1.1.X for interoperability
 */
private static final long serialVersionUID = 4112578634029874840L;

private static final Unsafe UNSAFE = Unsafe.getUnsafe();

/**
 * A property list that contains default values for any keys not
 * found in this property list.
 *
 * @serial
 */
protected volatile Properties defaults;

/**
 * Properties does not store values in its inherited Hashtable, but instead
 * in an internal ConcurrentHashMap.  Synchronization is omitted from
 * simple read operations.  Writes and bulk operations remain synchronized,
 * as in Hashtable.
 */
private transient volatile ConcurrentHashMap<Object, Object> map;
public synchronized Object setProperty(String key, String value) {
    return put(key, value);
}
@Override
public synchronized Object put(Object key, Object value) {
    return map.put(key, value);
}

Note this is not the complete source code of Properties. The complete implementation can be found in here: https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/util/Properties.java