SCJP Sun Certified Programmer By Kathy Sierra and Bert Bates - Part9

Couple of months back i started practicing SCJP Sun Certified Programmer for Java 5 Study Guide By Kathy Sierra and Bert Bates.

Great book written by Kathy Sierra and Bert Bates.

I wanted to share few important quotations found from the nineth chapter.

1) Besides the no-arg constructor and the constructor that takes a Runnable (the target, i.e., the instance with the job to do), there are other overloaded constructors in class Thread.

The constructors we care about are

Thread()

Thread(Runnable target)

Thread(Runnable target, String name)

Thread(String name)

2) The isAlive() method is the best way to determine if a thread has been started but has not yet completed its run() method.

3) The order in which runnable threads are chosen to run is not guaranteed.

4) A thread can be only in one of five states

a) New :- This is the state the thread is in after the Thread instance has been created, but the start() method has not been invoked on the thread.

b) Runnable :- This is the state a thread is in when it's eligible to run, but the scheduler has not selected it to be the running thread. A thread first enters the runnable state when the start() method is invoked, but a thread can also return to the runnable state after either running or coming back from a blocked, waiting, or sleeping state. When the thread is in the runnable state, it is considered alive.

c) Running :- This is the state a thread is in when the thread scheduler selects it (from the runnable pool) to be the currently executing process.

d) Waiting/blocked/sleeping :- The thread is still alive, but is currently not eligible to run. In other words, it is not runnable, but it might return to a runnable state later if a particular event occurs.

e) Dead :- A thread is considered dead when its run() method completes.

5) Threads always run with some priority, usually represented as a number between 1 and 10 (although in some cases the range is less than 10). The scheduler in most JVMs uses preemptive, priority-based scheduling (which implies some sort of time slicing).

6) Although the default priority is 5, the Thread class has the three following constants (static final variables) that define the range of thread priorities:

Thread.MIN_PRIORITY (1)
Thread.NORM_PRIORITY (5)
Thread.MAX_PRIORITY (10)

7) The non-static join() method of class Thread lets one thread "join onto the end" of another thread. If you have a thread B that can't do its work until another thread A has completed its work, then you want thread B to "join" thread A. This means that thread B will not become runnable until A has finished (and entered the dead state).

Thread t = new Thread();
t.start();
t.join();

8) There are three ways a running thread could leave the running state:

a) A call to sleep() Guaranteed to cause the current thread to stop executing for at least the specified sleep duration (although it might be interrupted before its specified time).

b) A call to yield() Not guaranteed to do much of anything, although typically it will cause the currently running thread to move back to runnable so that a thread of the same priority can have a chance.

c) A call to join() Guaranteed to cause the current thread to stop executing until the thread it joins with (in other words, the thread it calls join() on) completes, or if the thread it's trying to join with is not alive, however, the current thread won't need to back out.

Besides those three, we also have the following scenarios in which a thread might leave the running state:

The thread's run() method completes.

A call to wait() on an object

A thread can't acquire the lock on the object whose method code it's attempting to run.

The thread scheduler can decide to move the current thread from running to runnable in order to give another thread a chance to run.

9) We can't guarantee that a single thread will stay running throughout the entire atomic operation.

10) Following are the key points about locking and synchronization:

a) Only methods (or blocks) can be synchronized, not variables or classes.

b) Each object has just one lock.

c) Not all methods in a class need to be synchronized. A class can have both synchronized and non-synchronized methods.

d) If two threads are about to execute a synchronized method in a class, and both threads are using the same instance of the class to invoke the method, only one thread at a time will be able to execute the method. The other thread will need to wait until the first one finishes its method call. In other words, once a thread acquires the lock on an object, no other thread can enter any of the synchronized methods in that class (for that object).

e) If a class has both synchronized and non-synchronized methods, multiple threads can still access the class's non-synchronized methods!

f) If a thread goes to sleep, it holds any locks it has—it doesn't release them.

g) Thread can acquire more than one lock. For example, a thread can enter a synchronized method, thus acquiring a lock, and then immediately invoke a synchronized method on a different object, thus acquiring that lock as well. As the stack unwinds, locks are released again. Also, if a thread acquires a lock and then attempts to call a synchronized method on that same object, no problem. The JVM knows that this thread already has the lock for this object, so the thread is free to call other synchronized methods on the same object, using the lock the thread already has.

h) You can synchronize a block of code rather than a method.

11) Static methods can be synchronized.There is only one copy of the static data we're trying to protect, so we only need one lock per class to synchronize static methods—a lock for the whole class. There is such a lock; every class loaded in Java has a corresponding instance of java.lang.Class representing that class. It's that java.lang.Class instance whose lock is used to protect the static methods of the class (if they're synchronized).

12) wait(), notify(), and notifyAll() must be called from within a synchronized context! A thread can't invoke a wait or notify method on an object unless it owns that object's lock.

13) Note that if the thread calling wait() does not own the lock, it will throw an IllegalMonitorStateException.

14) wait() and notify() or notifyAll(), we should almost always also have a while loop around the wait() that checks a condition and forces continued waiting until the condition is met.

wait() and notify() or notifyAll() are defined on Object class and start(),yield(),sleep() and join() are declared in Thread class.

run() method is declared in Runnable class.

15) The sleep() method is a static method that sleeps the currently executing thread's state. One thread cannot tell another thread to sleep.