...
- The lock object might be accessible to hostile code that can acquire the lock and hold it indefinitely. We recommend that locks not be accessible outside of their containing package.
- A field referring to a lock object might be modified to refer to a different lock object. This can cause two critical sections of code that expect to lock on the same object to lock on different objects instead, or, two critical sections intending to lock on different objects may end up locking on the same shared object.
- Any object that supports the
java.util.concurrent.Lockinterface should not have its intrinsic lock used; as this may cause confusion and inconsistency during maintainance.
...