...
... even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.
Wiki Markup |
---|
In general, use client-side locking only when the documentation of the class recommends it. For example, the documentation of the wrapper method {{synchronizedList()}} of class {{java.util.Collections}} \[[API 06|AA. Java References#API 06]\] states: |
In order to guarantee serial access, it is critical that all access to the backing list is accomplished through the returned list. It is imperative that the user manually synchronize on the returned list when iterating over it. Failure to follow this advice may result in non-deterministic behavior.
...
This noncompliant code example uses a thread-safe class Book
that cannot be modifiedrefactored.
Code Block |
---|
final class Book { // May change its locking policy in the future to use private internal locks private final String title; private Calendar dateIssued; private Calendar dateDue; Book(String title) { this.title = title; } public synchronized void issue(int days) { dateIssued = Calendar.getInstance(); dateDue = Calendar.getInstance(); dateDue.add(Calendar.DAY_OF_MONTH, days); } public synchronized Calendar getDueDate() { return dateDue; } } |
...