Page History

Holding locks while performing time-consuming or blocking operations can severely degrade system performance and can result in starvation. Furthermore, deadlock can result if interdependent threads block indefinitely. Blocking operations include network, file, and console I/O (for example, Console.readLine()) and object serialization. Deferring a thread indefinitely also constitutes a blocking operation. Consequently, programs must not perform blocking operations while holding a lock.

Wiki MarkupWhen the JVM interacts with a file system that operates over an unreliable network, file I/O might incur a large performance penalty. In such cases, avoid file I/O over the network while holding a lock. File operations (such as logging) that could block waiting for the output stream lock or for I/O to complete could be performed in a dedicated thread to speed up task processing. Logging requests can be added to a queue, assuming that the queue's {{put()}} operation incurs little overhead as compared to file I/O \ [[Goetz 2006|AA. References#Goetz 06]\].

Noncompliant Code Example (Deferring a Thread)

...

The current object's monitor is immediately released upon entering the wait state. After the timeout period has elapsed, the thread resumes execution after reacquiring the current object's monitor.unmigrated-wiki-markup

According to the Java API class {{Object}} documentation \[ [API 2006|AA. References#API 06]\]

Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits. This method should only be called by a thread that is the owner of this object's monitor.

...

Bibliography

...

      08. Locking (LCK)      LCK10-J. Do not use incorrect forms of the double-checked locking idiom