Demystifying class loading problems, Part 1: An introduction to class loading and debugging toolsLearn how class loading works and how your JVM can help you sort out class loading problems  |
| Level: Intermediate Lakshmi Shankar (shankarl@uk.ibm.com), Java Technology Center Development Team, IBM Hursley Labs 29 Nov 2005 The class loading component is fundamental to the Java™ virtual machine. Though developers generally have a good grasp of the basics of class loading, when a problem occurs, they may have a hard time diagnosing and determining a solution. In this four-part article series, Lakshmi Shankar and Simon Burns discuss the various class loading problems that you may encounter in your Java development and illustrate why they occur and how to resolve them. The insights they provide should help you understand and resolve common Java exceptions, such as<script language="JavaScript" type="text/javascript"> </script> Class loaders are responsible for loading classes into the Java Virtual Machine (JVM). Simple applications can use the Java platform's built-in class loading facility to load their classes; more complex applications tend to define their own custom class loaders. No matter what kind of class loader you're using, however, there are many problems that can occur in the class loading process. If you want to avoid such problems, you need to understand the fundamental mechanics of class loading. When problems do occur, an appreciation of the available diagnostic features and debugging techniques should help you resolve them. In this series of articles, we'll provide an in-depth look at class loading problems and use comprehensive examples to illustrate them. The first section of this introductory article describes the fundamentals of class loading; the second introduces some JVM debugging features. The next three articles in this series will focus on resolving class loading exceptions and illustrate some of the trickier class loading problems that you may encounter. This section describes the core concepts of class loading to provide a knowledge base for the rest of this series. The class loader delegation model is the graph of class loaders that pass loading requests to each other. The bootstrap class loader is at the root of this graph. Class loaders are created with a single delegation parent and looks for a class in the following places:
A class loader first determines if it has been asked to load this same class in the past. If so, it returns the same class it returned last time (that is, the class stored in the cache). If not, it gives its parent a chance to load the class. These two steps repeat recursively and depth first. If the parent returns null (or throws a Because the parent class loader is always given the opportunity to load a class first, the class is loaded by the class loader nearest the root. This means that all core bootstrap classes are loaded by the bootstrap loader, which makes sure that the correct versions of classes such as Figure 1 shows the three standard class loaders: Figure 1. The class loader delegation model  Unlike all other class loaders , the bootstrap class loader (also known as the primordial class loader) cannot be instantiated by Java code. (Often, this is because it is implemented natively as part of the VM itself.) This class loader loads the core system classes from the boot classpath, which is normally the JAR files located in the jre/lib directory. However, you can modify this classpath using the The extension class loader (also known as the standard extensions class loader) is a child of the bootstrap class loader. Its primary responsibility is to load classes from the extension directories, normally located the jre/lib/ext directory. This provides the ability to simply drop in new extensions, such as various security extensions, without requiring modification to the user's classpath. The system class loader (also known as the application class loader) is the class loader responsible for loading code from the path specified by the Table 1 summarizes the command-line options for setting the classpaths of the three standard class loaders:
The loading of a class can essentially be broken down into three phases: loading, linking, and initializing. Most, if not all, problems relating to class loading can be tracked down to a problem occurring in one of these phases. Therefore, a thorough understanding of each phase helps in the diagnosing of class loading problems. The phases are illustrated in Figure 2: Figure 2. The phases of class loading  The loading phase consists of locating the required class file (by searching though the respective classpaths) and loading in the bytecode. Within the JVM, the loading process gives a very basic memory structure to the class object. Methods, fields, and other referenced classes are not dealt with at this stage. As a result, the class is not usable. Linking is the most complicated of the three phases. It can be broken down into three main stages:
During the initializing phase, any static initializers contained within a class are executed. At the end of this phase, static fields are initialized to their default values. At the end of these three phases, a class is fully loaded and is ready for use. Note that class loading can be performed in a lazy manner and therefore some parts of the class loading process may be done on first use of the class rather than at load time. There are two ways in which classes can be loaded -- explicitly or implicitly -- with subtle variations between the two. Explicit class loading occurs when a class is loaded using one of the following method calls:
When one of these methods is invoked, the class whose name is specified as an argument is loaded by the class loader. If the class is already loaded, then a reference is simply returned; otherwise, the loader goes through the delegation model to load the class. Implicit class loading occurs when a class is loaded as result of a reference, instantiation, or inheritance (not via an explicit method call). In each of these cases, the loading is initiated under the covers and the JVM resolves the necessary references and loads the class. As with explicit class loading, if the class is already loaded, then a reference is simply returned; otherwise, the loader goes through the delegation model to load the class. Classes are often loaded through a combination of explicit and implicit class loading. For example, a class loader could first load a class explicitly and then load all of its referenced classes implicitly.
The previous section introduced the fundamental principles of class loading. This section covers the variety of features built into the IBM JVM to assist debugging. Other JVMs may have similar debugging features available; refer to the appropriate documentation for details. You can turn on the IBM JVM's verbose output by using the Interpreting verbose output
All the classes that are loaded are listed, along with the JAR file or directory from which they were loaded. For example:
Verbose class output shows additional information, such as when superclasses are being loaded, and when static initializers are being run. Some example output follows:
Verbose output also shows some internally thrown exceptions (if they occur), including the stack trace. Resolving problems using -verbose It is often useful to know where class loaders look for classes and which class loader loads a particular class. You can obtain this information using the IBM Verbose Class Loading command-line option: This option also works on user-defined class loaders, as long as they directly or indirectly extend Interpreting IBM Verbose Class Loading output
Here, The class loaders are listed with parents before children because of the way that the standard delegation model works: Parents go first. Notice that there is no output for the bootstrap class loader. Output is only produced for class loaders that extend Resolving problems using IBM Verbose Class Loading A Javadump (also know as a Javacore) is another IBM diagnosis tool that you may find useful; to learn more about it, see the IBM Diagnostics Guide (see Resources for a link). A Javadump is generated by the JVM when one of the following events occurs:
The moment that Javadump is triggered, detailed information is recorded in a date-stamped text file saved in the current working directory. This information includes data about threads, locks, stacks, and so on, as well as a rich set of information about the class loaders in the system. Interpreting the class loading section of a Javadump
The following is a snapshot of the class loader information taken from a Javadump:
In this example, there are only the three standard class loaders:
The Classloader summaries section provides details about each class loader in the system, including the type of the class loader. In this series of articles, the types of interest are the primordial, extension, system, application, and delegation (used in reflection). The other types (shareable, middleware, and trusted) are used in the Persistent Reusable JVM, which is beyond the scope of these articles (see the Persistent Reusable JVM User Guide for more information; there's a link in the Resources section below). The summaries section also shows the parent class loader: The parent of the system class loader is The ClassLoader loaded classes section lists the classes loaded by each class loader. In this example, the system class loader has only loaded one class, Resolving problems using Javadumps Other types of problems that could be diagnosed using a Javadump include:
The IBM JVM has a built-in method tracing facility. This allows methods in any Java code (including the core system classes) to be traced without modification to the code. Because this facility can provide a large amount of data, you can control the level of trace in order to zero in on the information that you want. The option for enabling trace varies depending on the release of the JVM. For details of these options, refer to the IBM Diagnostics Guides (see Resources for a link). Here are some example command lines: To trace all
To trace the
Interpreting method trace output Each line of trace provides more information than shown above. Let's look at one of the above lines in full:
This tracing includes:
Resolving problems with method trace
|
70
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
