From “Thinking in Java” – Bruce Eckel

Thread states

A thread can be in any one of four states:

• New: The thread object has been created, but it hasn’t been started yet, so it cannot run.
• Runnable: This means that a thread can be run when the time-slicing mechanism has CPU cycles available for the thread. 
• Thus, the thread might or might not be running at any moment, but there’s nothing to prevent it from being run if the scheduler can arrange it; it’s not dead or blocked.
• Dead: The normal way for a thread to die is by returning from its run( ) method. Before it was deprecated in Java 2, you could also call stop( ), but this could easily put your program into an unstable state. There’s also a destroy( ) method (which has never been implemented, and probably never will be, so it’s effectively deprecated). You’ll learn about an alternative way to code a stop( ) equivalent later in the chapter.
• Blocked: The thread could be run, but there’s something that prevents it. 
• While a thread is in the blocked state, the scheduler will simply skip over it and not give it any CPU time. Until a thread reenters the runnable state, it won’t perform any operations.

Pipes

It’s often useful for threads to communicate with each other by using I/O. Threading libraries may provide support for inter-thread I/O in the form of pipes.
These exist in the Java I/O library as the classes PipedWriter (which allows a thread to write into a pipe) and PipedReader (which allows a different thread to read from the same pipe).
This can be thought of as a variation of the producer-consumer problem, where the pipe is the canned solution.

Becoming blocked

When a thread is blocked, there’s some reason that it cannot continue running. A thread can become blocked for the following reasons: 

• You’ve put the thread to sleep by calling sleep(milliseconds), in which case it will not be run for the specified time. 
• You’ve suspended the execution of the thread with wait( ). It will not become runnable again until the thread gets the notify( ) or notifyAll( ) message. We’ll examine these in the next section. 
• The thread is waiting for some I/O to complete. 
• The thread is trying to call a synchronized method on another object, and that object’s lock is not available. 

In fact, the only place you can call wait( ), notify( ), or notifyAll( ) is within a synchronized method or block (sleep( ) can be called within non-synchronized methods since it doesn’t manipulate the lock). 

Deadlocks

Deadlock can occur if four conditions are simultaneously met: 

1. Mutual exclusion: At least one resource used by the threads must not be shareable. In this case, a chopstick can be used by only one philosopher at a time. 
2. At least one process must be holding a resource and waiting to acquire a resource currently held by another process. That is, for deadlock to occur, a philosopher must be holding one chopstick and waiting for the other one. 
3. A resource cannot be preemptively taken away from a process. All processes must only release resources as a normal event. Our philosophers are polite and they don’t grab chopsticks from other philosophers.
4. A circular wait must happen, whereby a process waits on a resource held by another process, which in turn is waiting on a resource held by another process, and so on, until one of the processes is waiting on a resource held by the first process, thus gridlocking everything. In this example, the circular wait happens because each philosopher tries to get the left chopstick first and then the right. In the preceding example, the deadlock is broken by swapping the initialization order in the constructor for the last philosopher, causing that last philosopher to actually get the right chopstick first, then the left. 

From Tutorial Concurrrency – Vogella 

http://www.vogella.com/articles/JavaConcurrency/article.html

– Callable/Future

     – http://www.vogella.com/articles/JavaConcurrency/article.html#futures

     – special construct which gives the possibility to the caller of the thread to get synchronously a result (when Future.get() is called, the calling thread will wait, if necessary, until the execution is complete, and the will retrieve the result).

– ForkJoin (divide et impera via threads)

     – http://www.vogella.com/articles/JavaConcurrency/article.html#forkjoin

     – a kind of Divide et impera for threads, introduced in Java 7, which allows the programmer to distribute a complex task to several workers and then wait for the result (see JSR 166 for details).

From Concurrency tutorial Oracle

http://docs.oracle.com/javase/tutorial/essential/concurrency

Note that constructors cannot be synchronized — using the synchronized keyword with a constructor is a syntax error.
Synchronizing constructors doesn’t make sense, because only the thread that creates an object should have access to it while it is being constructed.

Warning: When constructing an object that will be shared between threads, be very careful that a reference to the object does not “leak” prematurely.
For example, suppose you want to maintain a List called instances containing every instance of class.
You might be tempted to add the following line to your constructor:

instances.add(this);

But then other threads can use instances to access the object before construction of the object is complete.

Intrinsic Locks and Synchronization

Synchronization is built around an internal entity known as the intrinsic lock or monitor lock.(The API specification often refers to this entity simply as a “monitor.”)
A thread is said to own the intrinsic lock between the time it has acquired the lock and released the lock.

Synchronized statements are also useful for improving concurrency with fine-grained synchronization.

Reentrant synchronization

Recall that a thread cannot acquire a lock owned by another thread. But a thread can acquire a lock that it already owns.
Allowing a thread to acquire the same lock more than once enables reentrant synchronization.
This describes a situation where synchronized code, directly or indirectly, invokes a method that also contains synchronized code,
and both sets of code use the same lock. Without reentrant synchronization, synchronized code would have to take many additional precautions  to avoid having a thread cause itself to block.

Starvation

Starvation describes a situation where a thread is unable to gain regular access to shared resources and is unable to make progress.

Livelock

A thread often acts in response to the action of another thread. If the other thread’s action is also a response to the action of another thread, then livelock may result. 

Immutable objects

An object is considered immutable if its state cannot change after it is constructed.
Maximum reliance on immutable objects is widely accepted as a sound strategy for creating simple, reliable code.

A Strategy for defining immutable objects

1. Don’t provide “setter” methods — methods that modify fields or objects referred to by fields.
2. Make all fields final and private.
3. Don’t allow subclasses to override methods. The simplest way to do this is to declare the class as final. A more sophisticated approach is to make the constructor private and construct instances in factory methods.
4. If the instance fields include references to mutable objects, don’t allow those objects to be changed:Don’t provide methods that modify the mutable objects.Don’t share references to the mutable objects. Never store references to external, mutable objects passed to the constructor; if necessary, create copies, and store references to the copies. Similarly, create copies of your internal mutable objects when necessary to avoid  returning the originals in your methods.

High level concurrency objects

ReentrantLock

• tryLock : method backs out if the lock is not available immediately 
• lockInterruptibly : acquires the lock if it is available and returns immediately.

Executor interfaces

• Executor, a simple interface that supports launching new tasks.
• ExecutorService, a subinterface of Executor, which adds features that help manage the lifecycle, both of the individual tasks and of the executor itself.
• ScheduledExecutorService, a subinterface of ExecutorService, supports future and/or periodic execution of tasks.