...
| Wiki Markup |
|---|
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="3aeb886df364f6c3-9ef857d3-47824ca2-a9ad8ee7-6cddc9551bef03f99a4c0e13"><ac:parameter ac:name="">CON20-EX1</ac:parameter></ac:structured-macro> *CON20-EX1:* It is permissible to start a background thread during class initialization provided the thread does not access any fields. For example, the {{ObjectPreserver}} class (based on \[[Patterns 02|AA. Java References#Patterns 02]\]) shown below provides a mechanism for storing object references, which prevents an object from being garbage-collected, even if the object is not dereferenced in the future. |
...
| Tasklist | ||||
|---|---|---|---|---|
| ||||
||Completed||Priority||Locked||CreatedDate||CompletedDate||Assignee||Name|| |T|M|F|1269649993019|1269700561582|rcs_mgr|"Starting and using background threads during class initialization can result in class initialization cycles and deadlock. *For instance,* the main thread responsible for performing class initialization *may* block waiting for the background thread, which in turn will wait for the main thread to finish class initialization." ... see suggested words in bold...I am also generally unsure about the use of "can" vs. "may" because deadlocks are a "possibility" so perhaps "may" should be used?| |
...
CON08CON19-J. Do not synchronize on objects that may be reusedinvoke ThreadGroup methods 11. Concurrency (CON) CON07CON21-J. Use private final lock objects to synchronize classes that may interact with untrusted code. Do not invoke Thread.run()