Inner Classes & Threads

Inner Classes

• A "regular" inner class is declared inside the curly braces of another class, but outside any method or other code block.
• An inner class is a full-fledged member of the enclosing (outer) class, so it can be marked with an access modifier as well as the abstract or final modifiers. (Never both abstract and final together— remember that abstract must be subclassed, whereas final cannot be subclassed).
• An inner class instance shares a special relationship with an instance of the enclosing class. This relationship gives the inner class access to all of the outer class's members, including those marked private.
• To instantiate an inner class, you must have a reference to an instance of the outer class.
• From code within the enclosing class, you can instantiate the inner class using only the name of the inner class, as follows: MyInner mi = new MyInner();
• From code outside the enclosing class's instance methods, you can instantiate the inner class only by using both the inner and outer class names, and a reference to the outer class as follows: MyOuter mo = new MyOuter();
• MyOuter.MyInner inner = mo.new MyInner();
• From code within the inner class, the keyword this holds a reference to the inner class instance. To reference the outer this (in other words, the instance of the outer class that this inner instance is tied to) precede the keyword this with the outer class name as follows: MyOuter.this;

Method-Local Inner Classes

• A method-local inner class is defined within a method of the enclosing class.
• For the inner class to be used, you must instantiate it, and that instantiation must happen within the same method, but after the class definition code.
• A method-local inner class cannot use variables declared within the method (including parameters) unless those variables are marked final.
• The only modifiers you can apply to a method-local inner class are abstract and final. (Never both at the same time, though.)

Anonymous Inner Classes

• Anonymous inner classes have no name, and their type must be either a subclass of the named type or an implementer of the named interface.
• An anonymous inner class is always created as part of a statement; don't forget to close the statement after the class definition with a curly brace. This is a rare case in Java, a curly brace followed by a semicolon.
• Because of polymorphism, the only methods you can call on an anonymous inner class reference are those defined in the reference variable class (or interface), even though the anonymous class is really a subclass or implementer of the reference variable type.
• An anonymous inner class can extend one subclass or implement one interface. Unlike non-anonymous classes (inner or otherwise), an anonymous inner class cannot do both. In other words, it cannot both extend a class and implement an interface, nor can it implement more than one interface.
• An argument-defined inner class is declared, defined, and automatically instantiated as part of a method invocation. The key to remember is that the class is being defined within a method argument, so the syntax will end the class definition with a curly brace, followed by a closing parenthesis to end the method call, followed by a semicolon to end the statement: });

Static Nested Classes

• Static nested classes are inner classes marked with the static modifier.
• A static nested class is not an inner class, it's a top-level nested class.
• Because the nested class is static, it does not share any special relationship with an instance of the outer class. In fact, you don't need an instance of the outer class to instantiate a static nested class. 
• Instantiating a static nested class requires using both the outer and nested class names as follows: BigOuter.Nested n = new BigOuter.Nested();
• A static nested class cannot access non-static members of the outer class, since it does not have an implicit reference to any outer instance (in other words, the nested class instance does not get an outer this reference).

Defining, Instantiating, and Starting Threads

• Threads can be created by extending Thread and overriding the public void run() method.
• Thread objects can also be created by calling the Thread constructor that takes a Runnable argument. The Runnable object is said to be the target of the thread.
• You can call start() on a Thread object only once. If start() is called more than once on a Thread object, it will throw a RuntimeException.
• It is legal to create many Thread objects using the same Runnable object as the target.
• When a Thread object is created, it does not become a thread of execution until its start() method is invoked. When a Thread object exists but hasn't been started, it is in the new state and is not considered alive.

Transitioning Between Thread States

• Once a new thread is started, it will always enter the runnable state.
• The thread scheduler can move a thread back and forth between the runnable state and the running state.
• For a typical single-processor machine, only one thread can be running at a time, although many threads may be in the runnable state.
• There is no guarantee that the order in which threads were started determines the order in which they'll run.
• There's no guarantee that threads will take turns in any fair way. It's up to the thread scheduler, as determined by the particular virtual machine implementation. If you want a guarantee that your threads will take turns regardless of the underlying JVM, you can use the sleep() method. This prevents one thread from hogging the running process while another thread starves. (In most cases, though, yield() works well enough to encourage your threads to play together nicely.)
• A running thread may enter a blocked/waiting state by a wait(), sleep(), or join() call. the lock for a synchronized block of code.
• When the sleep or wait is over, or an object's lock becomes available, the thread can only reenter the runnable state. It will go directly from waiting to running (well, for all practical purposes anyway).
• A dead thread cannot be started again.

Sleep, Yield, and Join 

• Sleeping is used to delay execution for a period of time, and no locks are released when a thread goes to sleep.
• A sleeping thread is guaranteed to sleep for at least the time specified in the argument to the sleep() method (unless it's interrupted), but there is no guarantee as to when the newly awakened thread will actually return to running.
• The sleep() method is a static method that sleeps the currently executing thread's state. One thread cannot tell another thread to sleep.
• The setPriority() method is used on Thread objects to give threads a priority of between 1 (low) and 10 (high), although priorities are not guaranteed, and not all JVMs recognize 10 distinct priority levels—some levels may be treated as effectively equal.
• If not explicitly set, a thread's priority will have the same priority as the priority of the thread that created it.
• The yield() method may cause a running thread to back out if there are runnable threads of the same priority. There is no guarantee that this will happen, and there is no guarantee that when the thread backs out there will be a different thread selected to run. A thread might yield and then immediately reenter the running state.
• The closest thing to a guarantee is that at any given time, when a thread is running it will usually not have a lower priority than any thread in the runnable state. If a low-priority thread is running when a high-priority thread enters runnable, the JVM will usually preempt the running low-priority thread and put the high-priority thread in.
• When one thread calls the join() method of another thread, the currently running thread will wait until the thread it joins with has completed. Think of the join() method as saying, "Hey thread, I want to join on to the end of you. Let me know when you're done, so I can enter the runnable state."

Concurrent Access Problems and Synchronized Threads

• synchronized methods prevent more than one thread from accessing an object's critical method code simultaneously.
• You can use the synchronized keyword as a method modifier, or to start a synchronized block of code.
• To synchronize a block of code (in other words, a scope smaller than the whole method), you must specify an argument that is the object whose lock you want to synchronize on.
• While only one thread can be accessing synchronized code of a particular instance, multiple threads can still access the same object's unsynchronized code.
• When a thread goes to sleep, its locks will be unavailable to other threads.
• static methods can be synchronized, using the lock from the java.lang.Class instance representing that class.

Communicating with Objects by Waiting and Notifying

• The wait() method lets a thread say, "there's nothing for me to do now, so put me in your waiting pool and notify me when something happens that I care about." Basically, a wait() call means "wait me in your pool," or "add me to your waiting list."
• The notify() method is used to send a signal to one and only one of the threads that are waiting in that same object's waiting pool.
• The notify() method can NOT specify which waiting thread to notify.
• The method notifyAll() works in the same way as notify(), only it sends the signal to all of the threads waiting on the object.
• All three methods—wait(), notify(), and notifyAll()—must be called from within a synchronized context! A thread invokes wait() or notify() on a particular object, and the thread must currently hold the lock on that object.

Deadlocked Threads 

• Deadlocking is when thread execution grinds to a halt because the code is waiting for locks to be removed from objects.
• Deadlocking can occur when a locked object attempts to access another locked object that is trying to access the first locked object. In other words, both threads are waiting for each other's locks to be released; therefore, the locks will never be released!
• Deadlocking is bad. Don't do it.