...
Starting and using background threads during class initialization can result in deadlock.
Rule | Severity | Likelihood |
|---|
Detectable | Repairable | Priority | Level |
|---|---|---|---|
TSM02-J | Low | Probable | Yes |
No |
P4 | L3 |
Automated Detection
| Tool | Version | Checker | Description |
|---|
| Parasoft Jtest |
|
|
|
| CERT. |
| TSM02.CSTART | Do not call the "start" method of threads from inside a constructor | ||||||||
| SonarQube |
| S2693 | Threads should not be started in constructors |
Bibliography
Chapter 8, "Lazy Initialization" | |
Chapter 5, "Creational Patterns, Singleton" |
Issue Tracking
| 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?| |
...
...