...
If a class uses a private final lock to synchronize shared data, subclasses must also use a private final lock. However, if a class uses intrinsic synchronization over the class object without documenting its locking policy, subclasses may not use intrinsic synchronization over their own class object, unless they explicitly document their locking policy. If the superclass documents its policy by stating that client-side locking is supported, the subclasses have the option of choosing between intrinsic locking over the class object and a private lock. Regardless of which is chosen, subclasses must document their locking policy. See CON15-J. Do not override thread-safe methods with methods that are not thread-safe for related information.
If these restrictions are not met, the object's intrinsic lock is not trustworthy. If all conditions are satisfied, the object gains no significant security from using a private final lock object and may synchronize using its own intrinsic lock. However, it is still best to use block synchronization using a private final lock object instead of method synchronization when the method contains non-atomic operations that either do not require any synchronization or can use a more fine-grained locking scheme involving multiple private final lock objects. Non-atomic operations can be decoupled from those that require synchronization and executed outside the synchronized block. For this reason, and for maintainability reasons, block synchronization using a private final lock object is generally recommended.
...