公司来了位傻员工

Qestion:
When should I use Thread.getContextClassLoader()?

Answer:
Although not frequently asked, this question is rather tough to correctly answer. It usually comes up during framework programming, when a good deal of dynamic class and resource loading goes on. In general, when loading a resource dynamically, you can choose from at least three classloaders: the system (also referred to as the application) classloader, the current classloader, and the current thread context classloader. The question above refers to the latter. Which classloader is the right one?

One choice I dismiss easily: the system classloader. This classloader handles -classpath and is programmatically accessible as ClassLoader.getSystemClassLoader(). All ClassLoader.getSystemXXX() API methods are also routed through this classloader. You should rarely write code that explicitly uses any of the previous methods and instead let other classloaders delegate to the system one. Otherwise, your code will only work in simple command-line applications, when the system classloader is the last classloader created in the JVM. As soon as you move your code into an Enterprise JavaBean, a Web application, or a Java Web Start application, things are guaranteed to break.

So, now we are down to two choices: current and context classloaders. By definition, a current classloader loads and defines the class to which your current method belongs. This classloader is implied when dynamic links between classes resolve at runtime, and when you use the one-argument version of Class.forName(), Class.getResource(), and similar methods. It is also used by syntactic constructs like X.class class literals (see "Get a Load of That Name!" for more details).

Thread context classloaders were introduced in Java 2 Platform, Standard Edition (J2SE). Every ThreadThread.setContextClassLoader() method. If you don't invoke this method following a Thread's construction, the thread will inherit its context classloader from its parent Thread. If you don't do anything at all in the entire application, all Threads will end up with the system classloader as their context classloader. It is important to understand that nowadays this is rarely the case since Web and Java 2 Platform, Enterprise Edition (J2EE) application servers utilize sophisticated classloader hierarchies for features like Java Naming and Directory Interface (JNDI), thread pooling, component hot redeployment, and so on. has a context classloader associated with it (unless it was created by native code). It is set via the

Why do thread context classloaders exist in the first place? They were introduced in J2SE without much fanfare. A certain lack of proper guidance and documentation from Sun Microsystems likely explains why many developers find them confusing.

In truth, context classloaders provide a back door around the classloading delegation scheme also introduced in J2SE. Normally, all classloaders in a JVM are organized in a hierarchy such that every classloader (except for the primordial classloader that bootstraps the entire JVM) has a single parent. When asked to load a class, every compliant classloader is expected to delegate loading to its parent first and attempt to define the class only if the parent fails

Sometimes this orderly arrangement does not work, usually when some JVM core
code must dynamically load resources provided by application developers. Take
JNDI for instance: its guts are implemented by bootstrap classes in

rt.jar

(starting with J2SE 1.3), but these core JNDI classes may
load JNDI providers implemented by independent vendors and potentially deployed
in the application's

-classpath

. This scenario calls for a parent
classloader (the primordial one in this case) to load a class visible to one of
its child classloaders (the system one, for example). Normal J2SE delegation
does not work, and the workaround is to make the core JNDI classes use thread
context loaders, thus effectively "tunneling" through the classloader hierarchy
in the direction opposite to the proper delegation.

By the way, the previous paragraph may have reminded you of something else:
Java API for XML Parsing (JAXP). Yes, when JAXP was just a J2SE extension, the
XML parser factories used the current classloader approach for bootstrapping
parser implementations. When JAXP was made part of the J2SE 1.4 core, the
classloading changed to use thread context classloaders, in complete analogy
with JNDI (and confusing many programmers along the way). See what I mean by
lack of guidance from Sun?

After this introduction, I have come to the crux of the matter: neither of
the remaining two choices is the right one under all circumstances. Some believe
that thread context classloaders should become the new standard strategy. This,
however, creates a very messy classloading picture if various JVM threads
communicate via shared data, unless all of them use the same context loader
instance. Furthermore, delegating to the current classloader is already a legacy
rule in some existing situations like class literals or explicit calls to

Class.forName()

(which is why, by the way, I recommend (again, see
"Get
a Load of That Name!
") avoiding the one-argument version of this method).
Even if you make an explicit effort to use only context loaders whenever you
can, there will always be some code not under your control that delegates to the
current loader. This uncontrolled mixing of delegation strategies sounds rather
dangerous.

To make matters worse, certain application servers set context and current
classloaders to different

ClassLoader

instances that have
the same
classpaths and yet are not related as a delegation parent
and child
. Take a second to think about why this is particularly
horrendous. Remember that the classloader that loads and defines a class is part
of the internal JVM's ID for that class. If the current classloader loads a
class

X

that subsequently executes, say, a JNDI lookup for some
data of type

Y

, the context loader could load and define

Y

. This

Y

definition will differ from the one by the
same name but seen by the current loader. Enter obscure class cast and loader
constraint violation exceptions.

This confusion will probably stay with Java for some time. Take any J2SE API
with dynamic resource loading of any kind and try to guess which loading
strategy it uses. Here is a sampling:

JNDI uses context classloaders

Class.getResource()

and

Class.forName()

use the
current classloader

JAXP uses context classloaders (as of J2SE 1.4)

java.util.ResourceBundle

uses the caller's current classloader

URL protocol handlers specified via

java.protocol.handler.pkgs

system property are looked up in the bootstrap and system classloaders only

Java Serialization API uses the caller's current classloader by default

Those class and resource loading strategies must be the most poorly
documented and least specified area of J2SE.

What is a Java programmer to do?

If your implementation is confined to a certain framework with articulated
resource loading rules, stick to them. Hopefully, the burden of making them work
will be on whoever has to implement the framework (such as an application server
vendor, although they don't always get it right either). For example, always use

Class.getResource()

in a Web application or an Enterprise JavaBean.

In other situations, you might consider using a solution I have found useful
in personal work. The following class serves as a global decision point for
acquiring the best classloader to use at any given time in the application (all
classes shown in this article are available with the download
):

public abstract class ClassLoaderResolver
{
/**
* This method selects the best classloader instance to be used for
* class/resource loading by whoever calls this method. The decision
* typically involves choosing between the caller's current, thread context,
* system, and other classloaders in the JVM and is made by the {@link IClassLoadStrategy}
* instance established by the last call to {@link #setStrategy}.
*
* @return classloader to be used by the caller ['null' indicates the
* primordial loader]
*/
public static synchronized ClassLoader getClassLoader ()
{
final Class caller = getCallerClass (0);
final ClassLoadContext ctx = new ClassLoadContext (caller);

return s_strategy.getClassLoader (ctx);
}
public static synchronized IClassLoadStrategy getStrategy ()
{
return s_strategy;
}
public static synchronized IClassLoadStrategy setStrategy (final IClassLoadStrategy strategy)
{
final IClassLoadStrategy old = s_strategy;
s_strategy = strategy;

return old;
}

/**
* A helper class to get the call context. It subclasses SecurityManager
* to make getClassContext() accessible. An instance of CallerResolver
* only needs to be created, not installed as an actual security
* manager.
*/
private static final class CallerResolver extends SecurityManager
{
protected Class [] getClassContext ()
{
return super.getClassContext ();
}

} // End of nested class

/*
* Indexes into the current method call context with a given
* offset.
*/
private static Class getCallerClass (final int callerOffset)
{
return CALLER_RESOLVER.getClassContext () [CALL_CONTEXT_OFFSET +
callerOffset];
}

private static IClassLoadStrategy s_strategy; // initialized in <clinit>

private static final int CALL_CONTEXT_OFFSET = 3; // may need to change if this class is redesigned
private static final CallerResolver CALLER_RESOLVER; // set in <clinit>

static
{
try
{
// This can fail if the current SecurityManager does not allow
// RuntimePermission ("createSecurityManager"):

CALLER_RESOLVER = new CallerResolver ();
}
catch (SecurityException se)
{
throw new RuntimeException ("ClassLoaderResolver: could not create CallerResolver: " + se);
}

s_strategy = new DefaultClassLoadStrategy ();
}
} // End of class.

You acquire a classloader reference by calling the

ClassLoaderResolver.getClassLoader()

static method and use the
result to load classes and resources via the normal

java.lang.ClassLoader

API. Alternatively, you can use this

ResourceLoader

API as a drop-in replacement for

java.lang.ClassLoader

:

public abstract class ResourceLoader
{
/**
* @see java.lang.ClassLoader#loadClass(java.lang.String)
*/
public static Class loadClass (final String name)
throws ClassNotFoundException
{
final ClassLoader loader = ClassLoaderResolver.getClassLoader (1);

return Class.forName (name, false, loader);
}
/**
* @see java.lang.ClassLoader#getResource(java.lang.String)
*/
public static URL getResource (final String name)
{
final ClassLoader loader = ClassLoaderResolver.getClassLoader (1);

if (loader != null)
return loader.getResource (name);
else
return ClassLoader.getSystemResource (name);
}
... more methods ...
} // End of class

The decision of what constitutes the best classloader to use is factored out
into a pluggable component implementing the

IClassLoadStrategy

interface:

public interface IClassLoadStrategy
{
ClassLoader getClassLoader (ClassLoadContext ctx);
} // End of interface

To help

IClassLoadStrategy

make its decision, it is given a

ClassLoadContext

object:

public class ClassLoadContext
{
public final Class getCallerClass ()
{
return m_caller;
}

ClassLoadContext (final Class caller)
{
m_caller = caller;
}

private final Class m_caller;
} // End of class

ClassLoadContext.getCallerClass()

returns the class whose code
calls into

ClassLoaderResolver

or

ResourceLoader

. This
is so that the strategy implementation can figure out the caller's classloader
(the context loader is always available as

Thread.currentThread().getContextClassLoader()

). Note that the
caller is determined statically; thus, my API does not require existing business
methods to be augmented with extra

Class

parameters and is suitable
for static methods and initializers as well. You can augment this context object
with other attributes that make sense in your deployment situation.

All of this should look like a familiar Strategy design pattern to you. The
idea is that decisions like "always context loader" or "always current loader"
get separated from the rest of your implementation logic. It is hard to know
ahead of time which strategy will be the right one, and with this design, you
can always change the decision later.

I have a default strategy implementation that should work correctly in 95
percent of real-life situations:

public class DefaultClassLoadStrategy implements IClassLoadStrategy
{
public ClassLoader getClassLoader (final ClassLoadContext ctx)
{
final ClassLoader callerLoader = ctx.getCallerClass ().getClassLoader ();
final ClassLoader contextLoader = Thread.currentThread ().getContextClassLoader ();

ClassLoader result;

// If 'callerLoader' and 'contextLoader' are in a parent-child
// relationship, always choose the child:

if (isChild (contextLoader, callerLoader))
result = callerLoader;
else if (isChild (callerLoader, contextLoader))
result = contextLoader;
else
{
// This else branch could be merged into the previous one,
// but I show it here to emphasize the ambiguous case:
result = contextLoader;
}

final ClassLoader systemLoader = ClassLoader.getSystemClassLoader ();

// Precaution for when deployed as a bootstrap or extension class:
if (isChild (result, systemLoader))
result = systemLoader;

return result;
}

... more methods ...
} // End of class

The logic above should be easy to follow. If the caller's current and context
classloaders are in a parent-child relationship, I always choose the child. The
set of resources visible to a child loader is normally a superset of classes
visible to its parent, so this feels like the right decision as long as
everybody plays by J2SE delegation rules.

It is when the current and the context classloaders are siblings that the
right decision is impossible. Ideally, no Java runtime should ever create this
ambiguity. When it happens, my code chooses the context loader: a decision based
on personal experience of when things work correctly most of the time. Feel free
to change that code branch to suit your taste. It is possible that the context
loader is a better choice for framework components, and the current loader is
better for business logic.

Finally, a simple check ensures that the selected classloader is not a parent
of the system classloader. This is a good thing to do if you are developing code
that might be deployed as an extension library.

Note that I intentionally do not look at the name of resources or classes
that will be loaded. If nothing else, the experience with Java XML APIs becoming
part of the J2SE core should have taught you that filtering by class names is a
bad idea. Nor do I trial load classes to see which classloader succeeds first.
Examining classloader parent-child relationships is a fundamentally better and
more predictable approach.

Although Java resource loading remains an esoteric topic, J2SE relies on
various load strategies more and more with every major platform upgrade. Java
will be in serious trouble if this area is not given some significantly better
design considerations. Whether you agree or not, I would appreciate your
feedback and any interesting pointers from your personal design experience.

 

This article originates from http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html?page=1