1. Diff between Green Thread and Native Thread ?
Green Thread is a thread machanism of JVM itself and Native thread is OS's thread machanism.
2. What is CountDownLatch in java concurrency ?
Ans: CountDownLatch
3. What is CyclicBarrier in java concurrency ?
Ans: CyclicBarrier and example 2
4. Diff between Lock, Intrinsic lock and Reentrant Sync ?
5. Executors vs Thread pool
6. Daemon Thread
7. How we can get all active threads from Thread class ?
http://www.journaldev.com/1162/java-multi-threading-concurrency-interview-questions-with-answers
Java
Threads Important points
A class invariant is a type of internal
invariant that applies to every instance of a class at all times, except when
an instance is in transition from one consistent state to another. A class
invariant can specify the relationships among multiple attributes, and should
be true before and after any method completes. For example, suppose you
implement a balanced tree data structure of some sort. A class invariant might
be that the tree is balanced and properly ordered.
A class is thread‐safe if it behaves
correctly when accessed from multiple threads, regardless of the scheduling or
interleaving of the execution of those threads by the runtime environment
To avoid race conditions, there must be a way
to prevent other threads from using a variable while we're in the middle of
modifying it
CHECK‐THEN‐ACT RACE CONDITION:‐ you observe something to be true (file X doesn't exist) and
then take action based on that observation (create X); but in fact the
observation could have become invalid between the time you observed it and the
time you acted on it (someone else created X in the meantime), causing a
problem (unexpected exception, overwritten data, file corruption).
Every Java object can implicitly act as a lock
for purposes of synchronization; these built‐in locks are called intrinsic locks or monitor locks
When a thread requests a lock that is already
held by another thread, the requesting thread blocks. But because intrinsic
locks are reentrant, if a thread tries to acquire a lock that it already holds,
the request succeeds. Reentrancy means that locks are acquired on a per‐thread rather than per‐invocation basis.
For each mutable state variable that may be
accessed by more than one thread, all
accesses to that variable must be performed with the same lock held. In this case, we say that the variable is guarded
by that lock. For every invariant that involves more than one variable, all the variables involved in that
invariant must be guarded by the same
lock .
Acquiring the lock associated with an object
does not prevent other threads from accessing that object ‐ the only thing that
acquiring a lock prevents any other thread from doing is acquiring that same lock
While synchronized methods can make individual
operations atomic, additional locking is required ‐ when multiple operations
are combined into a compound action.
Any access (get or set) to Global/state
variables should be done within the synchronized methods or same lock.This will
ensure the visibility of state variables across the threads i.e. To ensure that all threads see the most upto‐date values of shared
mutable variables, the reading and writing threads must synchronize on a common
lock.
There is no guarantee that operations in one
thread will be performed in the order given by the program, as long as the
reordering is not detectable from within that thread ‐ even if the reordering
is apparent to other threads.
When a field is declared volatile, the compiler and runtime are put on notice that this
variable is shared and that operations on it should not be reordered with other
memory operation
You can use volatile variables only when all the following criteria are met:
• Writes to the variable do not depend on its
current value, or you can ensure that only a single thread ever updates the value;
• The variable does not participate in
invariants with other state variables; and
•
Locking is not required for any other reason while the variable is being
accessed
Publishing an object means making it available to code outside of its
current scope, such as by storing a reference to it where other code can find
it, returning it from a non‐private method, or passing it to a method in another class.
To publish an object safely, both the
reference to the object and the object's state must be made visible to other
threads at the same time. A properly constructed object can be safely published
by:
•
Initializing an object reference from a static initializer;
• Storing a reference to it into a volatile
field or AtomicReference;
• Storing a reference to it into a final field
of a properly constructed object; or •
Storing a reference to it into a field that is properly guarded by a lock
The publication requirements for an object
depend on its mutability:
•
Immutable objects can be published through any mechanism;
• Effectively immutable objects must be safely
published;
• Mutable objects must be safely published,
and must be either thread‐safe or guarded by a lock.
An object that is published when it should not have been is said to have escaped.
If data is only accessed from a single thread,
no synchronization is needed. This technique, thread confinement, is one of the simplest ways to achieve thread
safety
Stack
confinement is a special case of thread confinement in
which an object can only be reached through local variables
Immutable
objects are always thread‐safe. An object is
immutable if:
• Its state cannot be
modified after construction;
• All its fields are final; and
• It is
properly constructed (the this reference does not escape during construction).
Race
conditions in accessing or updating multiple related
variables can be eliminated by using an immutable object to hold all the
variables. With a mutable holder object,
you would have to use locking to ensure atomicity; with an immutable one, once
a thread acquires a reference to it, it need never worry about another thread
modifying its state. If the variables are to be updated, a new holder object is
created, but any threads working with the previous holder still see it in a
consistent state
The most useful policies for using and sharing
objects in a concurrent program are:
Thread-confined. A thread‐confined object is owned exclusively by and confined to one
thread, and can be modified by its owning thread.
Shared
read-only. A shared read‐only object can be accessed concurrently by multiple threads
without additional synchronization, but cannot be modified by any thread.
Shared read‐only objects include
immutable and effectively immutable objects.
Shared
thread-safe. A thread‐safe object performs synchronization internally, so multiple
threads can freely access it through its public interface without further
synchronization
Guarded. A guarded object can be accessed only with a specific lock
held. Guarded objects include those that are encapsulated within other thread‐safe objects and
published objects that are known to be guarded by a specific lock.
When an object is encapsulated within another object, all code paths that have access
to the encapsulated object are known and can be therefore be analyzed more
easily than if that object were accessible to the entire program. Combining
confinement with an appropriate locking discipline can ensure that otherwise
non‐thread‐safe objects are used in
a thread‐safe manner.
An object following the Java monitor pattern
encapsulates all its mutable state and guards it with the object's own
intrinsic lock. The Java monitor pattern is useful when building classes from
scratch or composing classes out of objects that are not thread‐safe.
The safest way to add a new atomic operation
is to modify the original class to support the desired operation, but this is not always possible
because you may not have access to the source code or may not be free to modify
it. 2. Another approach is to extend the class, assuming it was designed for
extension. E.g:-BetterVector in extends Vector to add a putIfAbsent method
