java.lang.Class klass = Myclass.class;

一旦一个类被载入JVM中，同一个类就不会被再次载入了（切记，同一个类）。这里存在一个问题就是什么是“同一个类”？正如一个对象有一个具体的状态，即标识，一个对象始终和其代码(类)相关联。同理，载入JVM的类也有一个具体的标识，我们接下来看。

在JAVA中，一个类用其完全匹配类名(fully qualified class name)作为标识，这里指的完全匹配类名包括包名和类名。但在JVM中一个类用其全名和一个加载类ClassLoader的实例作为唯一标识。因此，如果一个名为Pg的包中，有一个名为Cl的类，被类加载器KlassLoader的一个实例kl1加载，Cl的实例，即C1.class在JVM中表示为(Cl, Pg, kl1)。这意味着两个类加载器的实例(Cl, Pg, kl1) 和 (Cl, Pg, kl2)是不同的，被它们所加载的类也因此完全不同，互不兼容的。那么在JVM中到底有多少种类加载器的实例？下一节我们揭示答案。

				

				
						类加载器
				
		

				

				

				

				

				

				

				

				

				
在JVM中，每一个类都被java.lang.ClassLoader的一些实例来加载.类ClassLoader是在包中java.lang里，开发者可以自由地继承它并添加自己的功能来加载类。

无论何时我们键入java MyMainClass来开始运行一个新的JVM，“引导类加载器(bootstrap class loader)”负责将一些关键的Java类，如java.lang.Object和其他一些运行时代码先加载进内存中。运行时的类在JRE\lib\rt.jar包文件中。因为这属于系统底层执行动作，我们无法在JAVA文档中找到引导类加载器的工作细节。基于同样的原因，引导类加载器的行为在各JVM之间也是大相径庭。
同理，如果我们按照如下方式：

log(java.lang.String.class.getClassLoader());

protected synchronized Class<?> loadClass
    (String name, boolean resolve)
    throws ClassNotFoundException{

    // First check if the class is already loaded
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClass0(name);
            }
        } catch (ClassNotFoundException e) {
            // If still not found, then invoke
            // findClass to find the class.
            c = findClass(name);
        }
    }
    if (resolve) {
            resolveClass(c);
    }
    return c;
}

public class MyClassLoader extends ClassLoader{

    public MyClassLoader(){
        super(MyClassLoader.class.getClassLoader());
    }
}

public class MyClassLoader extends ClassLoader{

    public MyClassLoader(){
        super(getClass().getClassLoader());
    }
}

    protected Class<?> findClass(String name)
        throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }

Target target3 = (Target) target2;

    public void fx(){
        log("this = " + this + "; Version.fx(1).");
    }

    static{
        log("client.TaskImpl.class.getClassLoader
        (v1) : " + TaskImpl.class.getClassLoader());
    }

    public void execute(){
        log("this = " + this + "; execute(1)");
    }

public byte[] findClassBytes(String className){

        try{
            String pathName = currentRoot +
                File.separatorChar + className.
                replace('.', File.separatorChar)
                + ".class";
            FileInputStream inFile = new
                FileInputStream(pathName);
            byte[] classBytes = new
                byte[inFile.available()];
            inFile.read(classBytes);
            return classBytes;
        }
        catch (java.io.IOException ioEx){
            return null;
        }
    }

    public Class findClass(String name)throws
        ClassNotFoundException{

        byte[] classBytes = findClassBytes(name);
        if (classBytes==null){
            throw new ClassNotFoundException();
        }
        else{
            return defineClass(name, classBytes,
                0, classBytes.length);
        }
    }

    public Class findClass(String name, byte[]
        classBytes)throws ClassNotFoundException{

        if (classBytes==null){
            throw new ClassNotFoundException(
                "(classBytes==null)");
        }
        else{
            return defineClass(name, classBytes,
                0, classBytes.length);
        }
    }

    public void execute(String codeName,
        byte[] code){

        Class klass = null;
        try{
            klass = findClass(codeName, code);
            TaskIntf task = (TaskIntf)
                klass.newInstance();
            task.execute();
        }
        catch(Exception exception){
            exception.printStackTrace();
        }
    }

public class Client{

    public static void main (String[] args){

        try{
            byte[] code = getClassDefinition
                ("client.TaskImpl");
            serverIntf.execute("client.TaskImpl",
                code);
            }
            catch(RemoteException remoteException){
                remoteException.printStackTrace();
            }
        }

    private static byte[] getClassDefinition
        (String codeName){
        String userDir = System.getProperties().
            getProperty("BytePath");
        FileSystemClassLoader fscl1 = null;

        try{
            fscl1 = new FileSystemClassLoader
                (userDir);
        }
        catch(FileNotFoundException
            fileNotFoundException){
            fileNotFoundException.printStackTrace();
        }
        return fscl1.findClassBytes(codeName);
    }
}

public void execute(String codeName, byte[] code)throws RemoteException{

        FileSystemClassLoader fileSystemClassLoader = null;

        try{
            fileSystemClassLoader = new FileSystemClassLoader();
            fileSystemClassLoader.execute(codeName, code);
        }
        catch(Exception exception){
            throw new RemoteException(exception.getMessage());
        }
    }

示例在differentversionspush文件夹下。服务端和客户端的控制台界面分别如图10，11，12所示：

                                                            图10. 定制类加载器执行引擎

图10显示的是定制的类加载器控制台。我们可以看到client.TaskImpl的代码被多次加载。实际上针对每一个客户端，类都被加载并初始化。


    图11. 定制类加载器，客户端1

    图11中，含有client.TaskImpl.class.getClassLoader(v1)的日志记录的类TaskImpl的代码被客户端的VM加载，然后送到服务端。图12 另一个客户端把包含有client.TaskImpl.class.getClassLoader(v1)的类代码加载并送往服务端。


图12. 定制类加载器，客户端1

这段代码演示了我们如何利用不同的类加载器实例来在同一个VM上执行不同版本的代码。

J2EE的类加载器

J2EE的服务器倾向于以一定间隔频率，丢弃原有的类并重新载入新的类。在某些情况下会这样执行，而有些情况则不。同样，对于一个web服务器如果要丢弃一个servlet实例，可能是服务器管理员的手动操作，也可能是此实例长时间未相应。当一个JSP页面被首次请求，容器会把此JSP页面翻译成一个具有特定形式的servlet代码。一旦servlet代码被创建，容器就会把这个servlet翻译成class文件等待被使用。对于提交给容器的每次请求，容器都会首先检查这个JSP文件是否刚被修改过。是的话就重新翻译此文件，这可以确保每次的请求都是及时更新的。企业级的部署方案以.ear, .war, .rar等形式的文件，同样需要重复加载，可能是随意的也可能是依照某种配置方案定期执行。对所有的这些情况——类的加载、卸载、重新加载……全部都是建立在我们控制应用服务器的类加载机制的基础上的。实现这些需要扩展的类加载器，它可以执行由其自身所定义的类。Brett Peterson已经在他的文章 Understanding J2EE Application Server Class Loading Architectures给出了J2EE应用服务器的类加载方案的详细说明，详见网站TheServerSide.com。

结要

本文探讨了类载入到虚拟机是如何进行唯一标识的，以及类如果存在同样的类名和包名时所产生的问题。因为没有一个直接可用的类版

　　对象泄漏
　　游戏程序员跟其他程序员一样――他们也需要理解 Java 运行时环境的一些微妙之处，比如垃圾收集。垃圾收集可能是使您感到难于理解的较难的概念之一, 因为它并不能总是毫无遗漏地解决 Java 运行时环境中堆管理的问题。似乎有很多类似这样的讨论，它的开头或结尾写着：“我的问题是关于垃圾收集”。

　　假如您正面遭遇内存耗尽（out-of-memory）的错误。于是您使用检测工具想要找到问题所在，但这是徒劳的。您很容易想到另外一个比较可信的原因：这是 Java 虚拟机堆管理的问题,而不会认为这是您自己的程序的缘故。但是，正如 Java 游戏社区的资深专家不止一次地解释的，Java 虚拟机并不存在任何被证实的对象泄漏问题。实践证明，垃圾收集器一般能够精确地判断哪些对象可被收集，并且重新收回它们的内存空间给 Java 虚拟机。所以，如果您遇到了内存耗尽的错误，那么这完全可能是由您的程序造成的，也就是说您的程序中存在着“无意识的对象保留（unintentional object retention）”。

　　内存泄漏与无意识的对象保留
　　内存泄漏和无意识的对象保留的区别是什么呢？对于用 Java 语言编写的程序来说，确实没有区别。两者都是指在您的程序中存在一些对象引用，但实际上您并不需要引用这些对象。一个典型的例子是向一个集合中加入一些对象以便以后使用它们，但是您却忘了在使用完以后从集合中删除这些对象。因为集合可以无限制地扩大，并且从来不会变小，所以当您在集合中加入了太多的对象（或者是有很多的对象被集合中的元素所引用）时，您就会因为堆的空间被填满而导致内存耗尽的错误。垃圾收集器不能收集这些您认为已经用完的对象，因为对于垃圾收集器来说，应用程序仍然可以通过这个集合在任何时候访问这些对象，所以这些对象是不可能被当作垃圾的。

　　对于没有垃圾收集的语言来说，例如 C++ ，内存泄漏和无意识的对象保留是有区别的。C++ 程序跟 Java 程序一样，可能产生无意识的对象保留。但是 C++ 程序中存在真正的内存泄漏，即应用程序无法访问一些对象以至于被这些对象使用的内存无法释放且返还给系统。令人欣慰的是，在 Java 程序中，这种内存泄漏是不可能出现的。所以，我们更喜欢用“无意识的对象保留”来表示这个令 Java 程序员抓破头皮的内存问题。这样，我们就能区别于其他使用没有垃圾收集语言的程序员。

　　跟踪被保留的对象
　　那么当发现了无意识的对象保留该怎么办呢？首先，需要确定哪些对象是被无意保留的，并且需要找到究竟是哪些对象在引用它们。然后必须安排好 应该在哪里释放它们。最容易的方法是使用能够对堆产生快照的检测工具来标识这些对象，比较堆的快照中对象的数目，跟踪这些对象，找到引用这些对象的对象，然后强制进行垃圾收集。有了这样一个检测器，接下来的工作相对而言就比较简单了:

　　等待直到系统达到一个稳定的状态，这个状态下大多数新产生的对象都是暂时的，符合被收集的条件；这种状态一般在程序所有的初始化工作都完成了之后。
　　强制进行一次垃圾收集，并且对此时的堆做一份对象快照。
　　进行任何可以产生无意地保留的对象的操作。
　　再强制进行一次垃圾收集，然后对系统堆中的对象做第二次对象快照。
　　比较两次快照，看看哪些对象的被引用数量比第一次快照时增加了。因为您在快照之前强制进行了垃圾收集，那么剩下的对象都应该是被应用程序所引用的对象，并且通过比较两次快照我们可以准确地找出那些被程序保留的、新产生的对象。
　　根据您对应用程序本身的理解，并且根据对两次快照的比较，判断出哪些对象是被无意保留的。
　　跟踪这些对象的引用链，找出究竟是哪些对象在引用这些无意地保留的对象，直到您找到了那个根对象，它就是产生问题的根源。

　　显式地赋空（nulling）变量
　　一谈到垃圾收集这个主题，总会涉及到这样一个吸引人的讨论，即显式地赋空变量是否有助于程序的性能。赋空变量是指简单地将 null 值显式地赋值给这个变量，相对于让该变量的引用失去其作用域。

清单 1. 局部作用域

public static String scopingExample(String string) {
  StringBuffer sb = new StringBuffer();
  sb.append("hello ").append(string);
  sb.append(", nice to see you!");
  return sb.toString();
}

　　当该方法执行时，运行时栈保留了一个对 StringBuffer 对象的引用，这个对象是在程序的第一行产生的。在这个方法的整个执行期间，栈保存的这个对象引用将会防止该对象被当作垃圾。当这个方法执行完毕，变量 sb 也就失去了它的作用域，相应地运行时栈就会删除对该 StringBuffer 对象的引用。于是不再有对该 StringBuffer 对象的引用，现在它就可以被当作垃圾收集了。栈删除引用的操作就等于在该方法结束时将 null 值赋给变量 sb。

　　错误的作用域
　　既然 Java 虚拟机可以执行等价于赋空的操作，那么显式地赋空变量还有什么用呢？对于在正确的作用域中的变量来说，显式地赋空变量的确没用。但是让我们来看看另外一个版本的 scopingExample 方法，这一次我们将把变量 sb 放在一个错误的作用域中。

清单 2. 静态作用域

static StringBuffer sb = new StringBuffer();
public static String scopingExample(String string) {
  sb = new StringBuffer();
  sb.append("hello ").append(string);
  sb.append(", nice to see you!");
  return sb.toString();
}

　　现在 sb 是一个静态变量，所以只要它所在的类还装载在 Java 虚拟机中，它也将一直存在。该方法执行一次，一个新的 StringBuffer 将被创建并且被 sb 变量引用。在这种情况下，sb 变量以前引用的 StringBuffer 对象将会死亡，成为垃圾收集的对象。也就是说，这个死亡的 StringBuffer 对象被程序保留的时间比它实际需要保留的时间长得多――如果再也没有对该 scopingExample 方法的调用，它将会永远保留下去。

　　一个有问题的例子
　　即使如此，显式地赋空变量能够提高性能吗？我们会发现我们很难相信一个对象会或多或少对程序的性能产生很大影响，直到我看到了一个在 Java Games 的 Sun 工程师给出的一个例子，这个例子包含了一个不幸的大型对象。

清单 3. 仍在静态作用域中的对象

private static Object bigObject;

public static void test(int size) {
  long startTime = System.currentTimeMillis();
  long numObjects = 0;
  while (true) {
    //bigObject = null; //explicit nulling
    //SizableObject could simply be a large array, e.g. byte[]
    //In the JavaGaming discussion it was a BufferedImage
    bigObject = new SizableObject(size);
    long endTime = System.currentTimeMillis();
    ++numObjects;
    // We print stats for every two seconds
    if (endTime - startTime >= 2000) {
      System.out.println("Objects created per 2 seconds = " + numObjects);
      startTime = endTime;
      numObjects = 0;
    }
  }
}

　　这个例子有个简单的循环，创建一个大型对象并且将它赋给同一个变量，每隔两秒钟报告一次所创建的对象个数。现在的 Java 虚拟机采用 generational 垃圾收集机制，新的对象创建之后放在一个内存空间（取名 Eden）内，然后将那些在第一次垃圾收集以后仍然保留的对象转移到另外一个内存空间。在 Eden，即创建新对象时所在的新一代空间中，收集对象要比在“老一代”空间中快得多。但是如果 Eden 空间已经满了，没有空间可供分配，那么就必须把 Eden 中的对象转移到老一代空间中，腾出空间来给新创建的对象。如果没有显式地赋空变量，而且所创建的对象足够大，那么 Eden 就会填满，并且垃圾收集器就不能收集当前所引用的这个大型对象。所产生的后果是，这个大型对象被转移到“老一代空间”，并且要花更多的时间来收集它。

　　通过显式地赋空变量，Eden 就能在新对象创建之前获得自由空间，这样垃圾收集就会更快。实际上，在显式赋空的情况下，该循环在两秒钟内创建的对象个数是没有显式赋空时的5倍――但是仅当您选择创建的对象要足够大而可以填满 Eden 时才是如此, 在 Windows 环境、Java虚拟机 1.4 的默认配置下大概需要 500KB。那就是一行赋空操作产生的 5 倍的性能差距。但是请注意这个性能差别产生的原因是变量的作用域不正确，这正是赋空操作发挥作用的地方，并且是因为所创建的对象非常大。

　　最佳实践
　　这是一个有趣的例子，但是值得强调的是，最佳实践是正确地设置变量的作用域，而不要显式地赋空它们。虽然显式赋空变量一般应该没有影响，但总有一些反面的例子证明这样做会对性能产生巨大的负面影响。例如，迭代地或者递归地赋空集合内的元素使得这些集合中的对象能够满足垃圾收集的条件，实际上是增加了系统的开销而不是帮助垃圾收集。请记住这是个有意弄错作用域的例子，其实质是一个无意识的对象保留的例子。