Java Reference
In-Depth Information
within your own code, you have a second class that extends the MyCustomClassLoader
class, that class must also register itself as parallel-capable.
For most classloaders, these are the only two steps that are required. The recommended way
to write a classloader is to override the findClass() method. Custom classloaders that in-
stead override the loadClass() method must also ensure that the defineClass() method is
called only once for each class name within each classloader instance.
As with all performance issues involving scalability around a lock, the net performance be-
nefit of this optimization depends on how long the code in the lock is held. As a simple ex-
ample, consider this code:
URL url = new
new File ( args [ 0 ]). toURL ();
URLClassLoader ucl = new
new URLClassLoader ( url );
for ( String className : classNames ) {
ucl . loadClass ( className );
The custom classloader here will look in a single JAR file (passed on the command line as
the first element of args ). Then it loops through an array of class names (defined elsewhere)
and loads each of the classes from that JAR file.
The parent classloader here is the system classpath classloader. When two or more threads
execute this loop concurrently, they will have to wait for each other as they delegate the
lookup of the class into the classpath classloader. Table 12-2 shows the performance of this
loop when the system classpath is empty.
Table 12-2. Time to load classes concurrently (no classpath)
Number of threads Time in JDK 7 Time in JDK 6
30.353 seconds 27.696 seconds
34.811 seconds 31.409 seconds
48.106 seconds 72.208 seconds
117.34 seconds 184.45 seconds
Search WWH ::

Custom Search