Concurency Flashcards
Can atomicBoolean be used in place of a Boolean?
No it does not extend Boolean
Features of volatile
The value seen by a thread is always reread from main memory before use.
Any value written by a thread is always flushed through to main memory before the instruction completes
AtomicInteger isn’t an Integer but it does extend Number…
Yes
Lock interface in java.util .concurrent.locks. This ships with a couple of implementations…
ReentrantLock—This is essentially the equivalent of the familiar lock used in Java synchronized blocks, but it’s slightly more flexible.
ReentrantReadWriteLock—This can provide better performance in cases where there are many readers but few writers
The Lock interface can be used to completely replicate any functionality that is offered by block-structured concurrency…
Yes
The CountDownLatch is a simple synchronization pattern that allows for multiple threads to all agree on a minimum amount of preparation that must be done before any thread can pass a synchronization barrier…
Yes
Synchronization is required for reliable communication between threads as well as for mutual exclusion
Yes
TimeUnit.SECONDS.sleep(1)is valid sleep functionality
Yes
This optimization is known as hoisting, and it is precisely what the HotSpot server VM does…
In the absence of synchronization, it’s quite acceptable for the virtual machine to transform this code: while (!done) i++;
into this code:
if (!done) while (true) i++;
synchronization has no effect unless both read and write operations are synchronized over a common used variable
Yes
While the volatile modifier performs no mutual exclusion, it guarantees that any thread that reads the field will see the most recently written value…
Yes
If you need only inter-thread communication, and not mutual exclusion, the volatile modifier is an acceptable form of synchronization, but it can be tricky to use correctly…
Yes
If you need only inter-thread communication, and not mutual exclusion, the volatile modifier is an acceptable form of synchronization, but it can be tricky to use correctly…
Yes
As a rule, you should do as little work as possible inside synchronized regions…
Yes
How many kinds of tasks are…
There are two kinds of tasks: Runnable and its close cousin, Callable (which is like Runnable, except that it returns a value). The general mechanism for executing tasks is the executor service
The higher-level utilities in java.util.concurrent fall into three categories…
the Executor Framework, concurrent collections; and synchronizers.
Unless you have a compelling reason to do otherwise, use ConcurrentHashMap in preference to Collections.synchronizedMap or Hashtable
Yes
Under most circumstances, normal initialization is preferable to lazy initialization
Yes
If you use lazy initialization to break an initialization circularity, use a synchronized accessor, as it is the simplest, clearest alternative: // Lazy initialization of instance field - synchronized accessor private FieldType field;
synchronized FieldType getField() {
if (field == null) field = computeFieldValue(); return field}
Yes
If you need to use lazy initialization for performance on a static field, use thelazy initialization holder class idiom. This idiom (also known as the initializeon-demand holder class idiom) exploits the guarantee that a class will not be initialized until it is used [JLS, 12.4.1]. Here’s how it looks:
// Lazy initialization holder class idiom for static fields private static class FieldHolder {
static final FieldType field = computeFieldValue();
}
static FieldType getField() { return FieldHolder.field; }Yes
If you need to use lazy initialization for performance on an instance field, use the double-check idiom
Double-check idiom for lazy initialization of instance fields
private volatile FieldType field;
FieldType getField() {
FieldType result = field;
if (result == null) {
// First check (no locking)
synchronized(this) { result = field; if (result == null)
// Second check (with locking) field = result = computeFieldValue(); } } return resultYes
Prior to release 1.5, the double-check idiom did not work reliably because the semantics of the volatile modifier were not strong enough to support it…
Yes
Threads should not run if they aren’t doing useful work…
Yes thus while true is not effective
Threads should not busy-wait, repeatedly checking a shared object waiting for something to happen…
Yes
