@@ -399,6 +399,9 @@ Apart from the explanations why the partially blocking or racy code is safe, the
399399comments justifying such error-prone code and warning the developers that the code should be
400400modified and reviewed with double attention: see [ NB.3] ( #non-blocking-warning ) .
401401
402+ There is an inspection "Field accessed in both synchronized and unsynchronized contexts" in IntelliJ
403+ IDEA which helps to find classes with unbalanced synchronization.
404+ 402405<a name =" justify-volatile " ></a >
403406[ #] ( #justify-volatile ) Dc.9. Regarding every field with a ` volatile ` modifier: ** does it really need
404407to be ` volatile ` ** ? Does the Javadoc comment for the field explain why the semantics of ` volatile `
@@ -467,6 +470,9 @@ unbalanced synchronization is problematic.
467470See also [ RC.2] ( #unsafe-concurrent-point-read ) regarding unbalanced synchronization of read accesses
468471to mutable objects, such as collections.
469472
473+ There is a relevant inspection "Field accessed in both synchronized and unsynchronized contexts" in
474+ IntelliJ IDEA.
475+ 470476<a name =" server-framework-sync " ></a >
471477[ #] ( #server-framework-sync ) IS.4. ** Is the business logic written for server frameworks
472478thread-safe?** This includes:
@@ -485,6 +491,9 @@ properly synchronized or access only concurrent collections and classes.
485491synchronized** , e. g. if a ` DateFormat ` is stored in a static field? Although ` parse() ` and
486492` format() ` may look "read-only", they actually mutate the receiving ` DateFormat ` object.
487493
494+ An inspection "Non thread-safe static field access" in IntelliJ IDEA helps to catch such concurrency
495+ bugs.
496+ 488497### Excessive thread safety
489498
490499<a name =" pseudo-safety " ></a >
@@ -801,6 +810,9 @@ or some work that is done within a single thread could be split between several
801810which communicate via concurrent queues. See [ JCIP 5.3] for more information about the
802811producer-consumer pattern.
803812
813+ There is an inspection "Nested 'synchronized' statement" in IntelliJ IDEA corresponding to this
814+ item.
815+ 804816<a name =" document-locking-order " ></a >
805817[ #] ( #document-locking-order ) Dl.2. If restructuring a thread-safe class to avoid nested critical
806818sections is not reasonable, was it deliberately checked that the locks are acquired in the same
0 commit comments