@@ -93,6 +93,7 @@ Testing
9393 - [ Concurrent test workers coordinate their start?] ( #coordinate-test-workers )
9494 - [ There are more test threads than CPUs (if possible for the test)?] ( #test-workers-interleavings )
9595 - [ Assertions in parallel threads and asynchronous code are handled properly?] ( #concurrent-assert )
96+ - [ Checked the result of a ` CountDownLatch.await ` or ` Condition.await ` method call?] ( #check-await )
9697
9798Locks
9899 - [ Can use some concurrency utility instead of a lock with conditional ` wait ` (` await ` ) calls?
@@ -799,6 +800,21 @@ thread back to the main test thread and verify it in the end of the test, or to
799800[ ConcurrentUnit] ( https://github.com/jhalterman/concurrentunit ) library which takes over
800801the boilerplate associated with the first approach.
801802
803+ <a name =" check-await " ></a >
804+ [ #] ( #check-await ) T.6. ** Is the result of [ ` CountDownLatch.await ` ] (
805+ https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/CountDownLatch.html#await(long,java.util.concurrent.TimeUnit) ),
806+ and [ ` Condition.await ` ] (
807+ https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/locks/Condition.html#await(long,java.util.concurrent.TimeUnit) )
808+ method calls checked?** The most frequent form of this mistake is forgetting to wrap
809+ ` CountDownLatch.await() ` into ` assertTrue() ` in tests, which makes the test to not actually verify
810+ that the production code works correctly. The absence of a check in production code might cause
811+ race conditions.
812+ 813+ It's possible to find these problems using static analysis, e. g. by configuring the "Result of
814+ method call ignored" inspection in IntelliJ IDEA to recognize ` CountDownLatch.await ` and
815+ ` Condition.await ` . They are not in the default set of checked methods, so they should be added
816+ manually to the set in the inspection configuration.
817+ 802818<a name =" replacing-locks-with-concurrency-utilities " ></a >
803819### Locks
804820
@@ -1318,7 +1334,7 @@ https://guava.dev/releases/28.1-jre/api/docs/com/google/common/util/concurrent/L
13181334) describing this problem.
13191335
13201336<a name =" no-sleep-schedule " ></a >
1321- [ #] ( #no-sleep-schedule ) TE.8. ** A task or action is executed with a delay via a
1337+ [ #] ( #no-sleep-schedule ) TE.8. Is it possible to ** execute a task or an action with a delay via a
13221338[ ` ScheduledExecutorService ` ] (
13231339https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html )
13241340rather than by calling ` Thread.sleep() ` before performing the work** or submitting the task to
@@ -1327,7 +1343,7 @@ threads, while the approach with `Thread.sleep` requires a dedicated thread for
13271343action. Sleeping in the context of an unknown executor (if there is insufficient * concurrent access
13281344documentation* for the method, as per [ Dc.1] ( #justify-document ) , or if this is a
13291345concurrency-agnostic library method) before submitting the task to an executor is also bad: the
1330- context executor may not tolerate blocking calls such as ` Thread.sleep ` , see
1346+ context executor may not be well-suited for blocking calls such as ` Thread.sleep ` , see
13311347[ TE.4] ( #fjp-no-blocking ) for details.
13321348
13331349This item equally applies to scheduling one-shot and recurrent delayed actions, there are methods
0 commit comments