Brief Introduction to Java Classloader

There are two kinds of class loaders: one is provided by system, another is user-defined.  The system provides three class loaders: bootstrap (load JVM core classes), extensions (load JVM extension classes) and system (load classes defined on the classpath).  Developers do not need know details of these class loaders, only need to consider user-defined class loaders.

Delegation

Java class loaders uses the proxy pattern.  When a class loader tries to find a class, it will delegate this job to its parent class loader first, and its parent class loader will also do the same thing.  Finally, use bootstrap class loader to load the Java core classes.  This proxy pattern is to guarantee the Java core classes safe. Because when JVM compares two classes, it not only use class full name, it also compares class loaders of these two classes are same or not.  So if not use the proxy pattern, Java core classes may be loaded by different class loaders.  That will result a same Java core class will be identified as different ones by JVM.

Defining loader and initiating loader

java.lang.ClassLoader has two methods related load class: defineClass and loadClass.  The difference is that loadClass method will start the class loading process, but defineClass method will do the load class job finally.  The class loader starts the class loading may be different with the class loader finished the class loading.  The former called initiating loader, and the latter called defining loader.  When JVM compares whether two classes are same with each other, JVM will use the defining loader, other than the initiating loader.

Thread-context class loader

From JDK 1.2, thread-context class loader has been imported.  It used to solve that how to load SPI implementation classes.  Because SPI interfaces are part of Java core library, so these classes will be loaded by bootstrap class loader, but bootstrap class loader cannot load implementations.  Because these implementations are involved at 3rd party libraries.  Class loader proxy model cannot solve this problem.  With thread-context class loader, this problem can be solved.  Because by default, a thread-context class loader is the system class loader, so classes on the classpath can be loaded.  And developers can make the thread-context class loader changed in their code to fit the web container or OSGi environments.

Web container

The web container like Tomcat and Jetty defined their own class loaders and also apply the proxy pattern.  But different with common class loader, the proxy pattern of the web container class loader is reversed.  Because different web apps will use different libraries.  But when load the core Java library, the web container class loader  use the same order.

Java Concurrency: Fair Lock

When use synchronized, the order of threads acquire a lock is not same as the order of threads request to acquire a lock.  If you want to have a fair lock mechanism, you should use Java 5 Lock.

java.util.concurrent.locks.ReentrantLock has a constructor with a boolean parameter. With this constructor, you can have fair lock mechanism.  ReentrantLock has a queue to contain threads which want to acquire this lock.  When a thread releases this lock, then the header will acquire this lock if the queue is not empty.

Java Concurrency: Thread State

In Java, a thread has 5 kinds of states: NEW, RUNNABLE, BLOCKED, WAITING, TIMED_WAITING, TERMINATED. When you execute Thread.sleep(long), the current thread status will transform from RUNNABLE to TIMED_WAITING, and the current thread will give up CPU resources to another threads. But the current thread will not give up the monitor.

When execute Object.wait(), the current thread will become to WAITING state ( Object timed wait will make thread to TIMED_WAITING state ). But different with Thread.sleep(), Object.wait() will make thread to give up the monitor.

When your code use synchronized keyword try to acquire a monitor but blocked, the current thread will be at BLOCKED state. At that moment, the thread cannot respond to the interruption. But at WAITING and TIMED_WAITING state, a thread can have chance to respond to the interruption.

Different with synchronized, Lock.tryLock(long time, TimeUnit unit) can respond to the interruption. So use Lock in Java 5 concurrent is a way to avoid dead lock.