- Object
- The ultimate base class (java.lang.Object) for all Java classes (i.e. the root of all Java class hierarchies)
- Its finalize method is called by the garbage collector when it determines that there are no more references to an instance; overriding this method provides an opportunity to release resources (such as file descriptors or operating system graphic contexts) that might not be managed directly by the Java runtime; however, this method should not be used to perform essential activities since a Java program can terminate normally without garbage collection being invoked on a specific class instance
- Object Identity and Equality
- Identity: The check objRefA == objRefB will return true if both variables (objRefA and objRefB) reference the same object and false otherwise
- Equality: The Object class provides an equals method for performing a deep comparison between objects, i.e. to determine object equality based on the contents of the two objects; the default equals behavior in the Object class is the same as the one described above, i.e. it returns true if the two variables reference the same object and false otherwise
- However, specific subclasses implement their own equals behavior; for example, the String class implements equals such that string1.equals(string2) will return true even if the two variables point to distinct String objects as long as the two strings contain exactly the same sequence of characters
- The Object class also provides a hashCode method used to specify a value that uniquely identifies an object; any class that provides its own implementation of equals should also provide its own implementation of hashCode so that certain Collection classes that use hashCode to determine object equality will behave as desired
- Object References: A Java object can hold one of the following four types of references to another Java object
- STRONG: the mainstay; pins an object in memory such that it cannot be garbage collected; suitable for active references, e.g. a GUI needs to reference data objects that it is displaying; GUIs cannot function if they lose the reference
- WEAK: does not pin an object in memory; an object with only weak references in eligible for garbage collection; the JVM will attempt to reclaim memory by clearing out weak references prior to allocating another heap block; suitable for passive references, e.g. data objects need to reference GUIs in order to notify them when they change, data objects can function fine if they lose the reference
- SOFT: similar to weak references, except that they are (theoretically) garbage collected only when memory on the heap is low; once weak references have been reclaimed, if there is still not enough memory to satisfy the memory allocation request, the JVM will attempt to reclaim memory by clearing out soft references prior to allocating another heap block; suitable for convenience references, e.g. cached objects
- PHANTOM: used to track references to object that have already been garbage collected; useful for clean up or utilities, e.g. reporting on garbage collection activity; suitable for dead references, e.g. utilities needing to track garbage collection activity
- Access Modifiers (in increasing order of visibility)
- private: visible only inside the class
- none/default: visible to classes in the same package
- protected: visible to classes in the same package and subclasses in any package
- public: visible to all classes (in any package)
- General Modifiers
- static
- A field or method that is shared by all instances of the class
- Static variables are, therefore, also known as class variables (as opposed to instance variables)
- A static method can be used without instantiating the class and should, therefore, not use any non-static fields (i.e. instance fields)
- final
- In the context of a field, a constant
- In the context of a class, a class that cannot be subclassed
- abstract
- A class that cannot be instantiated
- An abstract class's methods may or may not be declared as abstract; abstract methods must be implemented by subclasses
- Object references may be specified to be of an abstract type, in which case they must be bound to either null or a non-abstract object that extends the abstract type
- Like an interface except that:
- it can participate in a class hierarchy (an interface can participate only in an interface hierarchy, not in a class hierarchy)
- it can provide a partial implementation
- it can define non-abstract methods (all methods of an interface are implicitly abstract)
- it can define methods with any level of access (all methods of an interface are implicitly public)
- it can not participate in multiple inheritance (a class can subclass only one class but it can implement multiple interfaces)
- it can declare and use fields (an interface can only declare static final constants)
- it can define constructors
- Typically defines the core ability of a class that extends it
- interface
- An abstract type that cannot be instantiated
- Can define method signatures and/or fields (methods are assumed to be abstract; fields are assumed to be static final)
- Object references may be specified to be of an interface type, in which case they must be bound to either null or an object that implements the interface
- Like an abstract class except that:
- it can not participate in a class hierarchy (an interface can participate only in an interface hierarchy, not in a class hierarchy)
- it can not provide a partial implementation
- it can not define non-abstract methods (all methods of an interface are implicitly abstract)
- it can not define methods with any level of access (all methods of an interface are implicitly public)
- it can participate in multiple inheritance (a class can subclass only one class but it can implement multiple interfaces)
- it can not declare and use fields (an interface can only declare static final constants)
- it can not define constructors
- A class that implements an interface but fails to implement all the methods specified by the interface must be declared as abstract
- Typically defines a peripheral ability of a class that implements it
- synchronized
- A method or block that is defined as synchronized will acquire a lock (exclusive access to the monitor) for the object (or class, in case the method is defined as static)
- transient
- Instance fields that are not automatically serializable
- volatile
- Informs the compiler that several threads might be simultaneously accessing this field (the data, therefore, always needs to be refreshed from memory rather than cached in a register)
- native
- Implies that the method is implemented elsewhere as platform-dependent code
- strictfp
- Implies that double and float expressions will be evaluated using FP-strict rules whereby intermediate results must be valid per IEEE standards
- static
- Passing Method Arguments
- Objects are passed by reference; however, object references are passed by value
- In other words, what is passed into methods are copies of references to objects, not copies of the objects themselves
- Consider the following code:
Obj obj = new Obj(); do(obj); void do(Obj objArg) { ... } - The object reference named objArg is a copy of the object reference named obj
- However, obj and objArg both point to the same instance of Obj
- Therefore, the reference is being passed into the method by value but, effectively, the object is being passed by reference
- If the method do() causes objArg to point to a different instance of Obj, that change is not visible outside the do() method; i.e. obj continues to point to the original object
- However, a modification made to the object referenced by objArg within the do() method is visible outside the do() method and is equivalent to making the same modification to the object referenced by the variable obj
- Since primitives are not objects, they are simply passed by value
- I/O
- Streams are for byte-based I/O
- Readers/Writers are for character-based I/O (i.e. multi-byte, formatted)
- Exceptions
- The hierarchy is as follows: Object(Throwable(Error, Exception(RuntimeException, CheckedException)))
- The Java facility to allow for the handling of unwanted error conditions such that the program has an opportunity to cope/recover (take distinct corrective action, manage flow of control, log the error, and/or inform the user) and continue execution; (see also the assert facility which allows for the program to end execution upon the detection of a serious inconsistency such as an incorrect checksum; the assert checking can be turned on or off at runtime and is useful for debugging)
- Managed via a try-catch-finally construct wherein the try block contains the program code (which might generate an exception), the catch block contains the code that will handle any exception that might be generated, and the finally block that can contain any cleanup code that might need to be executed prior to exiting the construct (this block will be executed regardless, even if some code prior to the finally block executes a return)
- Java has two primary types of exceptions
- Checked exceptions
- Subclasses of Exception
- Not preventable
- Represent conditions outside the control of the program
- Represent recoverable conditions, for example, bad user data input, database down, or network down (SQLException)
- When a method can throw an Exception (e.g. if it contains code that tries to execute some SQL), the exception must either be caught in the body of the method via a try-catch block or declared in the throws clause of the method declaration causing the exception handling to bubble up through the call stack (i.e. any method calling this method will need to either catch or throw the exception)
- Termed checked exceptions because the compiler checks the code to ensure that these exceptions are being caught/thrown per the required rules
- Also known as user-defined exceptions
- Although checked exceptions were thought of as a good idea when they were originally introduced, the current best practice is to avoid them because they break encapsulation and violate the Open/Closed Priciple because a new checked exception in method A causes all the methods up the hierarchy of each calling method to be impacted
- Throwing the exception in the method signature is a signal to the API user that this can happen and that the API user needs to be able either handle it or pass it on to its caller
- When overriding a method in a subclass, we cannot throw an exception that exists at a higher level of abstraction (i.e. superclass) than the exception thrown in the superclass
- Analogy: Parent asks child to order pizza from Tom's Pizza. Tom's Pizza says we don't deliver to your address. Child can either call the more expensive Bob's Pizza (handle the exception) or pass the exception on to the parent to handle. The answer depends on who is better to suited to handle the exception. Assuming that it is the parent's money, perhaps the parent is best suited to handle the exception.
- Unchecked exceptions
- Subclasses of RuntimeException
- Preventable
- Represent program defects, logic errors, or bugs; for example, IllegalArgumentException, NullPointerException, or IllegalStateException
- Termed runtime because they are thrown by the Java runtime, not by the program code
- Checked exceptions
- java.lang.ClassNotFoundException
- Thrown when the classloader is unable to find the reported class, typically because the class is missing from the CLASSPATH
- java.lang.NoClassDefFoundError
- Thrown when the classloader is unable to find a class being accessed by the reported class within a static block or static member
- Collections
- There are nine collection interfaces
- The base interface is Collection
- Five interfaces extend Collection: Set, List, SortedSet, Queue, and BlockingQueue
- Set (no duplicates) is implemented by the following:
- HashSet: hash table
- TreeSet: balanced binary tree based on TreeMap
- LinkedSet: ordering is predictable but not sorted (HashTable ordering is random, i.e. it changes over time); LinkedList and HashTable
- Stack:
- SortedSet: should only be used if it is truly essential to store data in sorted order and it isn't good enough to sort at presentation time
- List (ordered/sequenced, duplicates allowed) is implemented by the following:
- Vector: dynamic resizing array; good choice for rapid access to data; poor choice for frequently changing data since inserts and deletes are slow; thread-safe (and therefore slow as a result of multiple synchronized code blocks)
- ArrayList: thread-unsafe (and therefore faster) version of Vector; still suffers from poor performance on inserts and deletes
- LinkedList: actually, a doubly-linked list; good choice for sorting a list or for managing frequently changing data since inserts and deletes are very efficient (just require rewiring the before/after references in the succeeding/preceding nodes); poor choice when there is a frequent need to search for a specific node
- Stack:
- Set (no duplicates) is implemented by the following:
- Three other interfaces behave like collections but do not extend Collection: Map, SortedMap, and ConcurrentMap
- Map (key-value pairs) is implemented by the following:
- HashTable: uses the hash code of the object's key to store objects quickly; objects are organised into buckets wherein each bucket holds objects whose hash codes fall within a particular range; can hold very large data sets without impeding performance, which is O(1); however the performance is poor during resizing; thread-safe and therefore slower than thread-unsafe alternatives
- HashMap: a thread-unsafe version of HashTable
- IdentityHashMap: same as HashMap, except that objects are compared based on identity rather than equality (i.e. objects A and B are equal only if they refer to the same instance in memory; most other collections use equality via the equals and hashcode methods); therefore can contain duplicates as long as they are distinct instances
- WeakHashMap: same as HashMap, except that the keys are stored as weak references
- SortedMap is implemented by the following:
- LinkedHashMap: data storage is per the same technique as HashTable and HashMap except that a running LinkedList is maintained to track all the key in sorted order; slower than unsorted alternatives
- TreeMap: uses a balanced binary tree data structure rather than a hash map; inserts and deletes have O(log2(n)) efficiency; less efficient than LinkedHashMap's O(1) efficiency but a better option for large sets of data since is doesn't use an additional LinkedList to manage ordering
- Map (key-value pairs) is implemented by the following:
- Use wrappers to add behavior such as synchronization
- Use the following options to iterate over a collection
- java.util.Enumeration: can only iterate forward; generally replaced by Iterator, except perhaps in some J2ME situations
- java.util.Iterator: can only iterate forward
- java.util.ListIterator: can iterate forward and backward; only available for collections that implement the List interface
- All collection iterators exhibit fail-fast behavior in the case of illegal concurrent modification (ConcurrentModificationException), i.e. the iterators are designed to fail if the collection undergoes modification during iteration
- Skeletal implementations are provided by AbstractCollection, AbstractSet, AbstractList, AbstractSequentialList, and AbstractMap
- The Java language supports four kinds of types: interfaces, classes, arrays, and primitives; the first three are known as reference types; class instances and arrays are objects, primitive values are not; a class's members consist of its fields, methods, member classes, and member interfaces; a method's signature consists of its name and the types of its formal parameters; the signature does not include the method's return type
- Each primitive has a corresponding class type also known as a wrapper object; these primitive wrapper objectsare useful for various reasons such as storing constants such as the biggest and smallest values for each type, providing utility methods to convert to and from String types; additionally, some collections (e.g. java.util.SortedSet) operate only on the primitive wrappers, not on the primitives themselves
- main()
- The entry point into a program (i.e. a set of classes)
- When Java is asked to execute class X, it will execute the main() method defined by class X
- If class X does not define a main() method, then class X cannot be executed directly by Java
- A main() method may not be declared to throw an exception since it is called directly by the Java virtual machine and there is no application Java method below it in the call stack that could handle the exception
- Concurrency
- Re-entrancy Reentrancy
- 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 basis rather than a per invocation basis. This is contrary to how pthreads (POSIX threads) or mutexes behave, which is on a per invocation basis. Reentrancy facilitates the encapsulation of locking behavior and therefore simplifies the development of object-oriented concurrent code.
- There are two ways to create a thread:
- Create a class that subclasses the class Thread and overrides the run() method; then instantiate this class and call its start() method
- If the above is not possible because your thread class is already subclassing another class, then have your thread class implement the Runnable interface; this will force your thread class to implement the run() method; to start the thread, instantiate your thread class and pass it as an argument using code similar to the following: new Thread(instanceOfYourThreadClass).start();
- The start() method creates the system resources necessary to run the thread, schedules the thread to run, and calls the thread's run() method; at this point the thread is in the "Runnable" state; this state is called "Runnable" rather than "Running" because the thread might not actually be running when it is in this state; many computers have a single processor, making it impossible to run all "Runnable" threads at the same time
- A thread enters the "Not Runnable" state when one of these four events occurs:
- Someone invokes its sleep() method
- Someone invokes its suspend() method
- The thread uses its wait() method to wait on a condition variable
- The thread is blocking on I/O
- A thread exits the "Not Runnable" state when one of these four events occurs:
- If the thread had been put to sleep, then the specified number of milliseconds must elapse
- If the thread had been suspended, then someone must call its resume() method
- If the thread was waiting on a condition variable, then whatever object owns the variable must relinquish it by calling either notify() or notifyAll()
- If the thread was blocked on I/O, then the I/O must complete
- A thread dies when one of these two events occurs:
- The run() method completes
- Someone invokes its stop() method
- The Java runtime supports a very simple, deterministic scheduling algorithm known as fixed priority scheduling; this algorithm schedules threads based on their priority relative to other "Runnable" threads
- By default, a new thread inherits the priority of its parent thread; this priority can be modified at any time after its creation using the setPriority() method
- Thread priorities are integers ranging between Thread.MIN_PRIORITY (1) and Thread.MAX_PRIORITY (10); the default is Thread.NORM_PRIORITY (5)
- The Java thread scheduler uses a round-robin approach to choose between two equal priority "Runnable" threads
- The chosen thread will run until one of the following five events occurs:
- A higher priority thread becomes "Runnable" (preemptive thread scheduling)
- The chosen thread dies
- The chosen thread becomes "Not Runnable"
- Someone invokes the chosen thread's yield() method and there are one or more "Runnable" threads of the same priority as the chosen thread (otherwise, yield() is ignored)
- On systems that support time-slicing, the chosen thread's time allotment expires (the Java thread scheduler itself does not time-slice)
- Although the above is standard, the thread scheduler may choose to run a lower priority thread to prevent starvation
- A daemon is a special kind of thread that runs continuously, typically to execute a low priority background task or provide a service for other threads running in the same process; daemon threads exit when there are no non-daemon threads running in the process; the setDaemon(true) method is used to mark a thread as a daemon before it is started; an example is the garbage collector thread
- Locks
- A lock is also known as a mutex, semaphore (more accurately a binary semaphore), or monitor; there is no universal agreement on terminology
- Multi-threaded applications require locks to ensure that non-reentrant code is executed by one thread at a time
- Locks are implemented by using the "synchronized" keyword to mark blocks of code or entire methods representing non-reentrant code
- There are two types of locks: a class-level lock and an object-level lock; all static synchronized methods share a single class-level lock; all non-static synchronized blocks and methods share a single object-level lock (i.e. one shared lock per class instance); a lock is ON if a thread is executing code managed by the lock and OFF otherwise
- A lock is acquired upon entry into synchronized code and released upon exit, even if the exit occurs due to an exception
- A lock on the "this" object is implictly obtained via synchronized blocks and methods; a lock on an arbitrary class C may explicitly be obtained via the construct synchronized(C.class)
- A synchronized method can call itself recursively because the executing thread has already acquired the required lock; in other words, the lock is per-thread, not per-method-execution
- In the case of block synchronization, the target object is supplied as an argument; the most common argument is "this", e.g. synchronized(this); method synchronization assumes that the target object is the object that owns the method (i.e. "this")
- The synchronized modifier on a method is not considered part of the method signature and is, therefore, not automatically inherited when subclasses override methods from the superclass; accordingly, interface methods cannot be declared as synchronized; also, constructors cannot be qualified as synchronized although block synchronization can be used within constructors
- A wait/notify scheme is used by multiple synchronized blocks in an object to coordinate thread execution
- The object lock is turned ON once a thread starts to execute one of its synchronized blocks; others threads trying to access one of the object's synchronized blocks will be placed in a wait/suspended state
- When a resource (or condition) required to complete a synchronized block is unavailable, the synchronized block uses the wait() method to place the currently executing thread on the wait list and release the lock
- When resources become available, synchronized blocks use the notify() or notifyAll() methods to allow an arbitrary thread on the wait list to acquire the lock and proceed on with its work; notify() wakes one arbitrary thread on the wait list; notifyAll() wakes all threads on the wait list; regardless, only one thread can acquire the lock; the remaining threads must return to the wait list
- There is an overloaded form of wait() that timesout after the specified time period has elapsed instead of waiting for notify() or notifyAll()
- Although it might seem more efficient to use notify(), especially if all threads can be assumed to waiting on the same set of conditions, it is generally safer to use notifyAll()
- In the following example, the put() and get() methods are synchronized in order to ensure that put() and get() take turns and that a get() always follows a put(); therefore, the value returned by get() will always be the same as the argument most recently used to call put(); this structure models a message queue of type int with a capacity of exactly one; i.e., nothing can be added to the queue via a put() until the currently stored item has been retrieved via a get(); the alternative to this scheme would be what is called a race condition, wherein threads would call get() and put() in an indeterminate order
public class IntMessageQueueOfCapacityOne { private int contents; private boolean available = false; public synchronized int get() { while (available == false) { try { wait(); } catch (InterruptedException e) { } } available = false; notifyAll(); return contents; } public synchronized void put(int value) { while (available == true) { try { wait(); } catch (InterruptedException e) { } } contents = value; available = true; notifyAll(); } } - The join() method can be used to detect when a thread dies and whether it dies normally or abnormally
- The java.util.concurrent package implements a set of best practices, design patterns, and utilities analogous to the java.util.collections package
- The Executor interface forms the basis for frameworks to enable thread pooling, scheduled and periodic task execution, returning results, and long-running threads that can be queried for completion and cancelled
- The ConcurrentLinkedQueue, which is also part of the Java Collections Framework, enables multiple threads to share access to a common collection
- Classes that implement common synchronization idioms, such as a counting semaphore
- The java.util.concurrent.BlockingQueue class is based on a concept similar to IntMessageQueueOfCapacityOne described above
- The dining philosopher problem is the classic illustration of thread starvation proposed by Edsger Dijkstra in 1971; five philosophers (threads) are sitting around a dinner table; there are five chopsticks, one between each pair of adjacent philosophers such that each philosopher has a chopstick to his left and a chopstick to his right; in order to eat, a philosopher must pick up both chopsticks, but can only pick up one chopstick at a time; if each philosopher picks up the chopstick to his left, all five philosophers will perpetually wait for the chopstick to their right to become available, thereby resulting in starvation (pun intended)
- The release of a lock on object/class M followed by a subsequent matching acquisition of a lock on object/class M establishes a happens-before ordering such that the writes prior to the lock release are guaranteed to be visible upon the subsequent lock acquisition
- Re-entrancy Reentrancy
