JVM内部主要包括内存管理和Class Loader（类加载器）两个部分。熟悉了内存管理，我们就会清楚程序在内存中是怎么分配和执行的，就能解决所有和对象相关的问题（比如Memory Leak）。理解了Class Loader，就能解决所有类找不到（比如遇到NoClassDefFoundError或ClassNotFoundException）或配置文件找不到问题。

这次我们只讨论JVM的Class Loader，下次再讨论JVM的内存管理。

Class Loader的主要作用就是负责查找类并将其加载到内存中。有趣的是，Java中的Class Loader也是由Java所写，就和普通的class一样。这就产生了一个是鸡生蛋还是蛋生鸡的问题，到底第一个class由谁来加载呢？我们稍后会来讨论这个问题。

先来看一下Class Loader所具有的特点。

1.       继承关系

虽然Class Loader也是一个Java class，但这里的继承不是指定义class时使用的extends关键字来实现的继承，而是指由属性来维持的继承关系。即通过Class Loader的构造方法或其它方法显式的设置一个父Class Loader。

2.       代理关系

每一个Class Loader在接到请求去加载一个类之前（默认，访问一个类的时候，就会由加载当前类的Class Loader去加载被访问的类），它会首先请求它的父Class Loader来尝试加载，依次往上，如果父Class Loader加载成功，则直接返回，子Class Loader不再查找。

否则依次往下查找并加载。如果直到被请求的Class Loader也没有找到要加载的类，则会出现NoClassDefFoundError或ClassNotFoundException

当然如果被请求的类已经加载到了内存中，就不会触发这个查找过程了，而是直接返回已经加载的类。

我们来看一个例子，假设有图1中的Class Loader层次：

如果我们请求Class Loader E去加载Test.class，首先它会请求父Class Loader D去尝试加载。同样Class Loader D会先请求它的父Class Loader C去尝试加载Test.class。当然这里Class Loader C找不到Test.class，于是转回由Class Loader D去加载。最终Class Loader D成功找到了D:"Test.class，并将其加载到内存中。

同样，如果我们请求Class Loader F去加载Test3.class。Class Loader C和Class Loader D在各自的搜索范围内都找不到Test3.class。最终会由Class Loader F自己加载F:"Test3.class到内存中。

如果我们请求Class Loader D去加载Test3.class，最终就会出现NoClassDefFoundError或ClassNotFoundException

3.       同一继承链可见性

在同一个Class Loader对象的继承链中，下面被加载的类可以访问上面被加载的类，反之则不可以。

同样以图1为例，Test4.class可以访问到D:"Test.class和C:"Test2.class

而如果D:"Test.class或C:"Test2.class尝试访问Test4.class，就会出现NoClassDefFoundError或ClassNotFoundException

4.       多个继承链不可见性

多个继承链之间彼此看不到对方，不能相互访问。

还以图1为例，如果Test4.class访问Test3.class，或反过来Test3.class访问Test4.class，都会引起NoClassDefFoundError或ClassNotFoundException

理解了Class Loader所具有的特点，我们来看看JDK中都预置了哪些Class Loader。也是JVM启动时默认创建的Class Loader。如图2

通过图2，我们可以看到Bootstrap Class Loader是JVM中的祖先Class Loader。它是JDK中唯一一个由C++所写的Class Loader，它负责加载JDK的核心类库(rt.jar)以及另外两个由Java所写的Class Loader（Ext Class Loader和App Class Loader）。之后就功成身退，转由Ext Class Loader和App Class Loader加载所有应用中用到的类。

一般我们的应用都是通过设置CLASSPATH，最终由App Class Loader来加载。根据Class Loader的继承关系，我们应用中的类可以访问JDK的核心类库。反之则会出错。

我们再来看看WebLogic中Class Loader的层次关系（如图4）。如果需要，大家可以参考一下WebLogic中WAR和EAR的文件结构（如图3）

WLS中自定义了很多新的Class Loader，当然他们的祖先Class Loader都是JDK中的App (or System) Class Loader。我们来看一下每个Class Loader的职责。

1.       JDK App (or System) Class Loader

l       负责加载WLS启动脚本中CLASSPATH中设置的类

l       所有的类都会最先由它尝试加载

l       因为CLASSPATH的值在运行期不允许修改，所以由该Class Loader加载的类在运行期不能被动态卸载（替换）

2.       EJB Class Loader (1)

l       负责加载单独的EJB jar里的类。

l       不同的EJB jar文件会被不同实例的Class Loader加载，因此EJB jar彼此之间互相看不到对方

3.       WAR Class Loader (1)

l       负责加载单独的WAR里的类

l       不同的WAR文件会被不同实例的Class Loader加载，因此WAR彼此之间互相看不到对方

4.       EAR Class Loader

l       负责加载EAR里面的APP-INF下的类

l       不同的EAR文件会被不同实例的EAR Class Loader加载，因此EAR彼此之间互相看不到对方

l       它下面有一个EJB Class Loader (2) 实例,负责加载EAR里面所有的EJB jar。因此，EAR中的EJB彼此之间可以看到对方

l       EJB Class Loader (2) 下有多个WAR Class Loader (2) 实例。每个实例负责加载EAR里面的一个WAR。所以，EAR中的WAR彼此之间看不到对方

l       根据继承链规则，WAR可以看到所有的EJB及APP-INF下的所有类。 EJB可以看到APP-INF下的所有类，但反之则不可以

Class Loader虽然称为类加载器，但并不意味着只能用来加载Class，我们还可以利用它来查找图片和配置文件等资源。比如，我们经常使用getClass().getResourceAsStream(name)来查找配置文件。同样，查找其它资源文件的方式和上面一样，也会先请求父Class Loader来负责查找。

这里，我们只简单介绍了Class Loader对于类的查找，而关于Class Loader的具体加载、校验和初始化的过程，感兴趣的朋友可以参考《深入Java虚拟机》

"Thread-1" prio=6 tid=0x00c70bd8 nid=0x914 runnable [0x02ebf000..0x02ebfc68]
at java.util.HashMap.put(HashMap.java:420)
at TestLock$2.run(TestLock.java:20)

"Thread-0" prio=6 tid=0x00c70a50 nid=0x578 runnable [0x02e7f000..0x02e7fb68]
at java.util.HashMap.put(HashMap.java:420)
at TestLock$1.run(TestLock.java:11)

Socket ack是指当socket接收到数据之后，发送一个ack字符串(比如$ACK)给socket发送方。这样，socket发送方可以根据是否收到了ack判断对方是否收到了数据。

Socket ack是显示的在应用程序中加入的一种通讯协议。如果不使用ack，在socket通讯中，可能会丢失数据。

比如，socket client要连续的给socket server发送100条消息。如果我们在server收到第50条消息的时候，强行kill了server。那么查询client端发送的log，可能client端成功发送了51条。只有当client端发送第52条消息的时候才遇到异常。这样第51条消息就丢失了。

所以为了确保数据传输的准确性，我们可以引入ack协议。有时我们不仅要确保server不但收到了数据，而且还要保证server成功处理了数据。这时，可以等server成功处理完数据之后，再给client发ack。

2.       Socket Keep Alive

Socket连接像数据库连接一样，属于重量型资源。如果我们频繁的创建socket、发送/接收数据、关闭socket，那么会有很大一部分时间浪费在socket的创建和关闭上。

所以，如果我们经常需要与同一个socket地址发送/接收数据时，应该考虑只创建一次socket，然后一直使用这个socket对象发送/接收数据。

3.       Heartbeat

通常，我们会设置socket的receive timeout。这样，如果我们一直打开着socket (keep alive)， 而很长时间又没有数据通讯，socket接收方就会timeout，最终导致打开的连接坏掉。

如果很长时间没有数据通讯，防火墙或代理服务器也可能会关闭打开的socket连接。

所以为了保证打开的socket连接一直可用，如果一段时间没有数据进行通讯（或指定一个时间间隔），我们可以显示的发送一个heartbeat消息(比如: $HRT)给对方，从而保证连接不会被异常关闭。

4.       Socket Close

每一个socket对象会持有一个socket descriptor (其实就是file descriptor)，操作系统对于socket descriptor有一个最大限制。因此当socket不再使用时，一定要记得关闭，即使socket连接失败或出现异常，只要socket对象不为null，一定要记得关闭。

下面图显示了，当socket关闭时，socket的状态变化(socket状态可以通过netstat命令查看)。更详细的解释，可以google一下。

当主动一方调用close(先调用close)时的状态变化:

ESTABLISHED -> FIN_WAIT_1-> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

当被动一方调用close(后调用close)时的状态变化:

ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

通常，TIME_WAIT 是正常状态，过一段时间(2MSL, 1到4分钟)就会自动消失.

我们需要特别注意CLOSE_WAIT 状态：

1．   如果很长时间才消失，表明socket server处理太慢，很多client已经连接到server，发送完数据并close了。

2．   如果一直也不消失，表明有socket没有正常close (对方已经close了)

5.       SO_REUSEADDR Option

当socket主动调用close的时候，从上面可以知道，它最终会进入TIME_WAIT 状态，需要过1到4分钟，才能完全close。

当socket处于TIME_WAIT 状态时，它仍然占用正在使用的IP/PORT。这样，如果我们的程序(比如socket server)使用了一个固定的IP/PORT，当socket处于TIME_WAIT 状态时，程序将不能立即重启，会出现端口占用错误。

Socket提供了一个setReuseAddress()方法，可以设置当socket处于TIME_WAIT 状态时，是否允许其它进程绑定这个端口。

如果我们正在开发socket server，一定要记得调用ServerSocket.setReuseAddress(true).

Client socket也有这个方法，而且有时可能需要指明client连接server时所使用的本地IP/PORT(一般不用指明，系统会随机选择一个PORT)。但实际测试，在client socket上设置这个方法在Windows和Solaris下并不起作用。当socket处于TIME_WAIT 状态时，重启client仍然出现端口占用错误。上网搜索了很长时间，很多人都碰到了这个问题，可能是操作系统底层socket实现问题。因为测试使用C语言开发的socket client，同样也有这个错误。有人说LINUX下好用，还有就是可以尝试修改tcp_time_wait_interval来减小TIME_WAIT等待时间

1.       Socket Timeout

写Socket程序的时候需要注意设置下面的timeout，避免对方没有响应的时候，导致Socket程序挂起或等待时间过长

1.1         Accept Timeout

Accept timeout 仅对ServerSocket有用。ServerSocket 使用accept()方法来监听客户端Socket的连接。

默认，ServerSocket.accept() 方法会一直阻塞直到有客户端来连接。通常，我们不需要设置accept timeout.

但有时候特殊情况，还是要考虑设置accept timeout.

比如: 程序A给程序B发了一个JMS消息，然后程序A启动一个Socket Server，想通过socket等待接收程序B的返回消息。如果不设置accept timeout, 并且程序B因为某些原因一直不能连接Socket Server，最终会导致程序A挂起。

Accept Timeout可以这样设置：

ServerSocket serverSocket = new ServerSocket(5555);

serverSocket.setSoTimeout(5000); // in milliseconds

while (true) {

    Socket socket = serverSocket.accept();

        …

}

1.2         Connect Timeout

当Client端连接Server端的时候，可以指定Connect Timeout

如果没有指定，会使用操作系统的默认值:

Connect Timeout可以这样设置：

SocketAddress socketAddress = new InetSocketAddress(host, port);

socket = new Socket();

socket.connect(socketAddress, connectTimeout);

1.3         Receive Timeout

当socket从另一方接收数据时，可以设置Receive Timeout

默认没有timeout，socket会一直阻塞直到有数据可读取。

Receive Timeout可以这样设置：

Socket socket = new Socket(host, port);

socket.setSoTimeout(timeout);

1.4         Send Timeout

Send Timeout是socket给另一方发送数据时使用的。

不过Java里没有办法设置Send Timeout.

当然，socket发送数据的时候，会首先发送到本机OS的一个buffer内。一般只要一次发送的数据不是很大，即使对方挂起或暂时不能接收数据，也不会导致发送方挂起。