Linux 2.6内核中提高网络I/O性能的新方法—epoll I/O多路复用技术在比较多的TCP网络服务器中有使用.

1、为什么select落后

首先，在Linux内核中，select所用到的`FD_SET`是有限的，即内核中有个参数__FD_SETSIZE定义了每个FD_SET的句柄个数，在 我用的2.6.15-25-386内核中，该值是1024，搜索内核源代码得到：

include/linux/posix_types.h:

1

define __FD_SETSIZE         1024

也就是说，如果想要同时检测1025个句柄的可读状态是不可能用select实现的。或者 同时检测1025个句柄的可写状态也是不可能的。其次，内核中实现select是用轮询方法，即每次检测都会遍历所有FD_SET中的句柄，显然，select函数执行时间与FD_SET中的句柄个数有一个比例关系，即 select要检测的句柄数越多就会越费时。当然，在前文中我并没有提及poll方法，事实上用select的朋友一定也试过poll，我个人觉得 select和poll大同小异，个人偏好于用select而已。

2、内核中提高I/O性能的新方法epoll

epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。要使用epoll只需要这三个系统调用：epoll_create(2)， epoll_ctl(2)， epoll_wait(2)。

3、epoll的优点

• 支持一个进程打开大数目的socket描述符(FD)

  select 最不能忍受的是一个进程所打开的FD是有一定限制的，由FD_SETSIZE设置，默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显然太少了。这时候你一是可以选择修改这个宏然后重新编译内核，不过资料也同时指出这样会带来网络效率的下降，二是可以选择多进程的解决方案(传统的 Apache方案)，不过虽然linux上面创建进程的代价比较小，但仍旧是不可忽视的，加上进程间数据同步远比不上线程间同步的高效，所以也不是一种完 美的方案。不过epoll则没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右，具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

• IO 效率不随FD数目增加而线性下降

  传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合，不过由于网络延时，任一时间只有部分的socket是”活跃”的， 但是select/poll每次调用都会线性扫描全部的集合，导致效率呈现线性下降。但是epoll不存在这个问题，它只会对”活跃”的socket进行操作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么，只有”活跃”的socket才会主动的去调用 callback函数，其他idle状态socket则不会，在这点上，epoll实现了一个”伪”AIO，因为这时候推动力在os内核。在一些 benchmark中，如果所有的socket基本上都是活跃的—比如一个高速LAN环境，epoll并不比select/poll有什么效率，相反，如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

• 使用mmap加速内核与用户空间的消息传递。

  这点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝就很重要，在这点上，epoll是通过内核与用户空间mmap(内存映射)同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话，一定不会忘记手工 mmap这一步的。

• 内核微调

  这一点其实不算epoll的优点了，而是整个linux平台的优点。也许你可以怀疑linux平台，但是你无法回避linux平台赋予你微调内核的能力。比如，内核TCP/IP协议栈使用内存池管理sk_buff结构，那么可以在运行时 期动态调整这个内存pool(skb_head_pool)的大小— 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手的数据包队列长度)，也可以根据你平台内存大小动态调整。更甚至在一个数据包数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。

4、epoll的工作模式

令人高兴的是，2.6内核的epoll比其2.5开发版本的/dev/epoll简洁了许多，所以，大部分情况下，强大的东西往往是简单的。唯一有点麻烦是epoll有2种工作方式:LT和ET。

LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你 的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．
ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述 符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致 了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。

Redis是业界普遍应用的缓存组件，研究一个组件框架，最直观的办法就是从应用方的角度出发，将每个步骤的考虑一番，从这些步骤入手去研究往往能够最快的体会到一个组件框架的设计哲学。以Redis为例，每当发起一条请求时，redis是如何管理管理网络请求，收到请求后又是通过什么样的数据结构进行组织并操作内存，这些数据又是如何dump到磁盘实现持久化，再到多机环境下如何同步和保证一致性……本文就是从网络模型、数据结构设计与内存管理、持久化方法和多机四个角度简要描述了redis的设计和自己的一点体会。

一.网络模型

Redis是典型的基于Reactor的事件驱动模型，单进程单线程，高效的框架总是类似的。网络模型与select,epoll异步模型几乎一致。

Redis流程上整体分为接受请求处理器、响应处理器和应答处理器三个同步模块，每一个请求都是要经历这三个部分。

Redis集成了libevent/epoll/kqueue/select等多种事件管理机制，可以根据操作系统版本自由选择合适的管理机制，其中libevent是最优选择的机制。

Redis的网络模型有着所有事件驱动模型的优点，高效低耗。但是面对耗时较长的操作的时候，同样无法处理请求，只能等到事件处理完毕才能响应，比如删除redis中全量的key-value，整个操作时间较长，操作期间所有的请求都无法响应。所以了解清楚网络模型有助于在业务中扬长避短，减少长耗时的请求，尽可能多一些简单的短耗时请求发挥异步模型的最大的威力，事实上在Redis的设计中也多次体现这一点。

二.数据结构和内存管理

1.字符串

1.1 结构

Redis的字符串是对C语言原始字符串的二次封装，结构如下：

1
2
3
4
5

struct sdshdr {
    long len;
    long free;
    char buf[];
};

可以看出，每当定义一个字符串时，除了保存字符的空间，Redis还分配了额外的空间用于管理属性字段。

1.2 内存管理方式

动态内存管理方式，动态方式最大的好处就是能够较为充分的利用内存空间，减少内存碎片化，与此同时带来的劣势就是容易引起频繁的内存抖动，通常采用“空间预分配”和“惰性空间释放”两种优化策略来减少内存抖动，redis也不例外。

每次修改字符串内容时，首先检查内存空间是否符合要求，否则就扩大2倍或者按M增长；减少字符串内容时，内存并不会立刻回收，而是按需回收。

关于内存管理的优化，最基本的出发点就是浪费一点空间还是牺牲一些时间的权衡，像STL、tcmalloc、protobuf3的arena机制等采用的核心思路都是“预分配迟回收”，Redis也是一样的。

1.3 二进制安全

判断字符串结束与否的标识是len字段，而不是C语言的’\0’，因此是二进制安全的。
放心的将pb序列化后的二进制字符串存入redis。
简而言之，通过redis的简单封装，redis的字符串的操作更加方便，性能更友好，并且屏蔽了C语言字符串的一些需要用户关心的问题。

2.字典（哈希）

字典的底层一定是hash，涉及到hash一定会涉及到hash算法、冲突的解决方法和hash表扩容和缩容。

2.1 hash算法

Redis使用的就是常用的Murmurhash2，Murmurhash算法能够给出在任意输入序列下的散列分布性，并且计算速度很快。之前做共享内存的Local-Cache的需求时也正是利用了Murmurhash的优势，解决了原有结构的hash函数散列分布性差的问题。

2.2 hash冲突解决方法

链地址法解决hash冲突，通用解决方案没什么特殊的。多说一句，如果选用链地址解决冲突，那么势必要有一个散列性非常好的hash函数，否则hash的性能将会大大折扣。Redis选用了Murmurhash，所以可以放心大胆的采用链地址方案。

2.3 hash扩容和缩容

维持hash表在一个合理的负载范围之内，简称为rehash过程。
rehash的过程也是一个权衡的过程，在做评估之前首先明确一点，不管中间采用什么样的rehash策略，rehash在宏观上看一定是：分配一个新的内存块，老数据搬到新的内存块上，释放旧内存块。
老数据何时搬？怎么搬？就变成了一个需要权衡的问题。
第一部分的网络模型上明确的指出Redis的事件驱动模型特点，不适合玩长耗时操作。如果一个hashtable非常大，需要进行扩容就一次性把老数据copy过去，那就会非常耗时，违背事件驱动的特点。所以Redis依旧采用了一种惰性的方案：
新空间分配完毕后，启动rehashidx标识符表明rehash过程的开始；之后所有增删改查涉及的操作时都会将数据迁移到新空间，直到老空间数据大小为0表明数据已经全部在新空间，将rehashidx禁用，表明rehash结束。
将一次性的集中问题分而治之，在Redis的设计哲学中体现的淋漓尽致，主要是为了避免大耗时操作，影响Redis响应客户请求。

3.整数集合

变长整数存储，整数分为16/32/64三个变长尺度，根据存入的数据所属的类型，进行规划。
每次插入新元素都有可能导致尺度升级（例如由16位涨到32位），因此插入整数的时间复杂度为O（n）。这里也是一个权衡，内存空间和时间的一个折中，尽可能节省内存。

4.跳跃表

Redis的skilplist和普通的skiplist没什么不同，都是冗余数据实现的从粗到细的多层次链表，Redis中应用跳表的地方不多，常见的就是有序集合。
Redis的跳表和普通skiplist没有什么特殊之处。

5.链表

Redis的链表是双向非循环链表，拥有表头和表尾指针，对于首尾的操作时间复杂度是O(1)，查找时间复杂度O(n)，插入时间复杂度O(1)。
Redis的链表和普通链表没有什么特殊之处。

三.AOF和RDB持久化

AOF持久化日志，RDB持久化实体数据，AOF优先级大于RDB。

1.AOF持久化

机制：通过定时事件将aof缓冲区内的数据定时写到磁盘上。

2.AOF重写

为了减少AOF大小，Redis提供了AOF重写功能，这个重写功能做的工作就是创建一个新AOF文件代替老的AOF，并且这个新的AOF文件没有一条冗余指令。（例如对list先插入A/B/C，后删除B/C，再插入D共6条指令，最终状态为A/D，只需1条指令就可以）
实现原理就是读现有数据库的状态，根据状态反推指令，跟之前的AOF无关。同样，为了避免长时间耗时，重写工作放在子进程进行。

3.RDB持久化

SAVE和BGSAVE两个命令都是用于生成RDB文件，区别在于BGSAVE会fork出一个子进程单独进行，不影响Redis处理正常请求。
定时和定次数后进行持久化操作。
简而言之，RDB的过程其实是比较简单的，满足条件后直接去写RDB文件就结束了。

四.多机和集群

1.主从服务器

避免单点是所有服务的通用问题，Redis也不例外。解决单点就要有备机，有备机就要解决固有的数据同步问题。

1.1 sync——原始版主从同步

Redis最初的同步做法是sync指令，通过sync每次都会全量数据，显然每次都全量复制的设计比较消耗资源。改进思路也是常规逻辑，第一次全量，剩下的增量，这就是现在的psync指令的活。

1.2 psync

部分重同步实现的技术手段是“偏移序号+积压缓冲区”，具体做法如下：
（1）主从分别维护一个seq，主每次完成一个请求便seq+1，从每同步完后更新自己seq；
（2）从每次打算同步时都是携带着自己的seq到主，主将自身的seq与从做差结果与积压缓冲区大小比较，如果小于积压缓冲区大小，直接从积压缓冲区取相应的操作进行部分重同步；
（3）否则说明积压缓冲区不能够cover掉主从不一致的数据，进行全量同步。
本质做法用空间换时间，显然在这里牺牲部分空间换回高效的部分重同步，收益比很大。

2.集群

Redis的官方版集群尚未在工业界普及起来，下面主要介绍一下集群的管理体系和运转体系。

2.1 slot-集群单位

集群的数据区由slot组成，每个节点负责的slot是在集群启动时分配的。

2.2 客户请求

客户请求时如果相应数据hash后不属于请求节点所管理的slots，会给客户返回MOVED错误，并给出正确的slots。
从这个层面看，redis的集群还不够友好，集群内部的状态必须由客户感知。

2.3 容灾

主从服务器，从用于备份主，一旦主故障，从代替主。

通过Redis的研究，深刻体会到的一点就是：所有设计的过程都是权衡和割舍的过程。同样放到日常的工作和开发中也是如此，一句代码写的好不好，一个模块设计的是否科学，就从速度和内存的角度去衡量看是否需要优化，并去评估每一种优化会收益到什么，同时会损失什么，收益远大于损失的就是好的优化，这样往往对于开发和提升更有针对性，更能提高效率。

单例模式作为对象的一种创建模式，它的作用是确保某一个类在整个系统中只有一个实例，而且自行实例化并向整个系统提供这个实例。

由此可见，单例模式具有以下的特点：

1. 单例类只能有一个实例。
2. 单例类必须自己创建自己的唯一的实例。
3. 单例类必须给所有其他对象提供这一实例。

由于Java语言的特点，使得单例模式在Java语言的实现上有自己的特点。这些特点主要表现在单例类如何将自己实例化。

饿汉式单例类

饿汉式单例类是在Java语言里实现起来最为简便的单例类。其源代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class EagerSingleton {
	/** 通过静态变量初始化的类实例 */
	private static final EagerSingleton instance = new EagerSingleton();
	/**
	 * 私有的默认构造
	 */
	private EagerSingleton() {
	}
	/**
	 * 获取唯一类实例的静态工厂方法
	 * 
	 * @return
	 */
	public static EagerSingleton getInstance() {
		return instance;
	}
}

由Java语言类的初始化顺序可知，在这个类被加载时，静态变量会被初始化，此时类的私有构造会被调用。这时候，单例类的唯一实例就被创建出来了。

Java语言中单例类的一个最重要的特点是类的构造是私有的，从而避免外界使用构造子直接创建出任意多该类的实例。值得指出的是，由于构造是私有的，因此该类不能被继承。

懒汉式单例类

与饿汉式单例类相同之处是，懒汉式单例类的构造也是私有的。而与饿汉式单例类不同的是，懒汉式单例类在第一次被引用时将自己实例化。在懒汉式单例类被加载时，不会将自己实例化。其源代码如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class LazySingleton {
	/**
	 * 此时静态变量不能声明为final，因为需要在工厂方法中对它进行实例化
	 */
	private static volatile LazySingleton instance;
	/**
	 * 私有构造，确保无法在类外实例化该类
	 */
	private LazySingleton() {
	}
	/**
	 * synchronized关键字解决多个线程的同步问题
	 */
	public static synchronized LazySingleton getInstance() {
		if (instance == null) {
			instance = new LazySingleton();
		}
		return instance;
	}
}

对singleton对象使用volatile关键字进行限制，保证其对所有线程的可见性，并且禁止对其进行指令重排序优化; 静态工厂方法中synchronized关键字提供的同步是必须的，否则当多个线程同时访问该方法时，无法确保获得的总是同一个实例。然而我们也看到，在所有的代码路径中，虽然只有第一次引用的时候需要对instance变量进行实例化，但是synchronized同步机制要求所有的代码执行路径都必须先获取类锁。在并发访问比较低时，效果并不显著，但是当并发访问量上升时，这里有可能会成为并发访问的瓶颈。

双重检查锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class Singleton {
    private static volatile Singleton singleton = null;
 
    private Singleton(){}
 
    public static Singleton getSingleton(){
        if(singleton == null){
            synchronized (Singleton.class){
                if(singleton == null){
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }    
}

这种写法被称为“双重检查锁”，顾名思义，就是在getSingleton()方法中，进行两次null检查。看似多此一举，但实际上却极大提升了并发度，进而提升了性能。为什么可以提高并发度呢？就像上文说的，在单例中new的情况非常少，绝大多数都是可以并行的读操作。因此在加锁前多进行一次null检查就可以减少绝大多数的加锁操作，执行效率提高的目的也就达到了。

坑: volatile这个关键字。其实这个关键字有两层语义。第一层语义就是可见性。可见性指的是在一个线程中对该变量的修改会马上由工作内存（Work Memory）写回主内存（Main Memory），所以会马上反应在其它线程的读取操作中.volatile的第二层语义是禁止指令重排序优化。我们写的代码（尤其是多线程代码），由于编译器优化，在实际执行的时候可能与我们编写的顺序不同。编译器只保证程序执行结果与源代码相同，却不保证实际指令的顺序与源代码相同,引入多线程这种乱序就可能导致严重问题.

禁止指令重排优化这条语义直到jdk1.5以后才能正确工作。此前的JDK中即使将变量声明为volatile也无法完全避免重排序所导致的问题。所以，在jdk1.5版本前，双重检查锁形式的单例模式是无法保证线程安全的。

静态内部内

这种单例模式的写法，是著名的《Java Concurrency in Practice》一书中介绍对象的安全发布时介绍的。我们先来看它的源代码。

1
2
3
4
5
6
7
8
9
10
11

public class ResourceFactory {
	private static class ResourceHolder {
		public static Resource resource = new Resource();
	}
	public static Resource getResource() {
		return ResourceHolder.resource;
	}
}

要理解上面这种单例类的写法，你需要先学习一些关于Java虚拟机如何初始化一个类的知识。

在java虚拟机中，类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括了：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段。其中，验证、准备和解析三个部分统称为连接（Linking）。

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也被称为动态绑定或晚期绑定）。

什么情况下需要开始类加载的第一个阶段：加载。虚拟机规范中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。但是对于初始化阶段，虚拟机规范则是严格规定了有且只有四种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

1）遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这四条字节码指令最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

4）当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

这四种场景中的行为称为对一个类进行主动引用，除此之外所有引用类的方式，都不会触发类的初始化，被称为被动引用。以下是三个例子：

1）通过子类引用父类的静态字段，不会导致子类初始化。

2）通过数组定义来引用类，不会触发此类的初始化。

3）常量在编译阶段会存入调用类的常量池，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

（以上摘自《深入理解Java虚拟机》）

从上面介绍的知识可以知道，JVM将推迟ResourceHolder类的初始化，直到第一个代码访问路径调用getResource()方法。此时，由于ResourceHolder.resource是一个读取静态字段的主动引用，虚拟机将第一次加载ResourceHolder类，并且通过一个静态变量来初始化Resource实例。而其他访问getResource()方法的代码路径，并不需要同步。

不需要额外的同步，但是又能确保对象可见性的正确发布，这是由Java的虚拟机规范所决定的！上面这种单例模式的写法，体现出对虚拟机规范的深刻理解，实在是专家级别的写法。

注意:上面提到的所有实现方式都有两个共同的缺点：

• 都需要额外的工作(Serializable、transient、readResolve())来实现序列化，否则每次反序列化一个序列化的对象实例时都会创建一个新的实例。
• 可能会有人使用反射强行调用我们的私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

枚举写法(推荐)

只能包含单个元素的枚举类型

1
2
3
4
5
6
7
8
9
10

public enum Singleton {
    INSTANCE; //定义一个枚举的元素，就代表Singleton的一个实例
    private String name;
    public String getName(){
        return name;
    }
    public void setName(String name){
        this.name = name;
    }
}

使用枚举除了线程安全和防止反射强行调用构造器之外，还提供了自动序列化机制，防止反序列化的时候创建新的对象。因此，Effective Java推荐尽可能地使用枚举来实现单例。

调用方式：Singleton.INSTANCE.getName();

最后，不管采取何种方案，请时刻牢记单例的三大要点：

• 线程安全
• 延迟加载
• 序列化与反序列化安全

Synchronized这类线程同步的机制可以解决多线程并发问题，在这种解决方案下，多个线程访问到的，都是同一份变量的内容。为了防止在多线程访问的过程中，可能会出现的并发错误。不得不对多个线程的访问进行同步，这样也就意味着，多个线程必须先后对变量的值进行访问或者修改，这是一种以延长访问时间来换取线程安全性的策略。

而ThreadLocal类为每一个线程都维护了自己独有的变量拷贝。每个线程都拥有了自己独立的一个变量，竞争条件被彻底消除了，那就没有任何必要对这些线程进行同步，它们也能最大限度的由CPU调度，并发执行。并且由于每个线程在访问该变量时，读取和修改的，都是自己独有的那一份变量拷贝，变量被彻底封闭在每个访问的线程中，并发错误出现的可能也完全消除了。对比前一种方案，这是一种以空间来换取线程安全性的策略。

来看一个运用ThreadLocal来实现数据库连接Connection对象线程隔离的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
public class ConnectionManager {
	private static ThreadLocal<Connection> connectionHolder = new ThreadLocal<Connection>() {
		@Override
		protected Connection initialValue() {
			Connection conn = null;
			try {
				conn = DriverManager.getConnection(
						"jdbc:mysql://localhost:3306/test", "username",
						"password");
			} catch (SQLException e) {
				e.printStackTrace();
			}
			return conn;
		}
	};
	public static Connection getConnection() {
		return connectionHolder.get();
	}
	public static void setConnection(Connection conn) {
		connectionHolder.set(conn);
	}
}

通过调用ConnectionManager.getConnection()方法，每个线程获取到的，都是和当前线程绑定的那个Connection对象，第一次获取时，是通过initialValue()方法的返回值来设置值的。通过ConnectionManager.setConnection(Connection conn)方法设置的Connection对象，也只会和当前线程绑定。这样就实现了Connection对象在多个线程中的完全隔离。在Spring容器中管理多线程环境下的Connection对象时，采用的思路和以上代码非常相似。

到底ThreadLocal类是如何实现这种“为每个线程提供不同的变量拷贝”的呢？先来看一下ThreadLocal的set()方法的源码是如何实现的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

    /**
     * Sets the current thread's copy of this thread-local variable
     * to the specified value.  Most subclasses will have no need to 
     * override this method, relying solely on the {@link #initialValue}
     * method to set the values of thread-locals.
     *
     * @param value the value to be stored in the current thread's copy of
     *        this thread-local.
     */
    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

在这个方法内部我们看到，首先通过getMap(Thread t)方法获取一个和当前线程相关的ThreadLocalMap，然后将变量的值设置到这个ThreadLocalMap对象中，当然如果获取到的ThreadLocalMap对象为空，就通过createMap方法创建。

线程隔离的秘密，就在于ThreadLocalMap这个类。ThreadLocalMap是ThreadLocal类的一个静态内部类，它实现了键值对的设置和获取（对比Map对象来理解），每个线程中都有一个独立的ThreadLocalMap副本，它所存储的值，只能被当前线程读取和修改。ThreadLocal类通过操作每一个线程特有的ThreadLocalMap副本，从而实现了变量访问在不同线程中的隔离。因为每个线程的变量都是自己特有的，完全不会有并发错误。还有一点就是，ThreadLocalMap存储的键值对中的键是this对象指向的ThreadLocal对象，而值就是你所设置的对象了。

为了加深理解，我们接着看上面代码中出现的getMap和createMap方法的实现：

1
2
3

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

1
2
3

void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }

代码已经说的非常直白，就是获取和设置Thread内的一个叫threadLocals的变量，而这个变量的类型就是ThreadLocalMap，这样进一步验证了上文中的观点：每个线程都有自己独立的ThreadLocalMap对象。打开java.lang.Thread类的源代码，我们能得到更直观的证明：

1
2
3

/* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

那么接下来再看一下ThreadLocal类中的get()方法，代码是这么说的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

/**
     * Returns the value in the current thread's copy of this
     * thread-local variable.  If the variable has no value for the
     * current thread, it is first initialized to the value returned
     * by an invocation of the {@link #initialValue} method.
     *
     * @return the current thread's value of this thread-local
     */
    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;
        }
        return setInitialValue();
    }
    /**
     * Variant of set() to establish initialValue. Used instead
     * of set() in case user has overridden the set() method.
     *
     * @return the initial value
     */
    private T setInitialValue() {
        T value = initialValue();
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
        return value;
    }

这两个方法的代码告诉我们，在获取和当前线程绑定的值时，ThreadLocalMap对象是以this指向的ThreadLocal对象为键进行查找的，这当然和前面set()方法的代码是相呼应的。

进一步地，我们可以创建不同的ThreadLocal实例来实现多个变量在不同线程间的访问隔离，为什么可以这么做？因为不同的ThreadLocal对象作为不同键，当然也可以在线程的ThreadLocalMap对象中设置不同的值了。通过ThreadLocal对象，在多线程中共享一个值和多个值的区别，就像你在一个HashMap对象中存储一个键值对和多个键值对一样，仅此而已。

设置到这些线程中的隔离变量，会不会导致内存泄漏呢？ThreadLocalMap对象保存在Thread对象中，当某个线程终止后，存储在其中的线程隔离的变量，也将作为Thread实例的垃圾被回收掉，所以完全不用担心内存泄漏的问题。在多个线程中隔离的变量，光荣的生，合理的死，真是圆满，不是么？

最后再提一句，ThreadLocal变量的这种隔离策略，也不是任何情况下都能使用的。如果多个线程并发访问的对象实例只允许，也只能创建那么一个，那就没有别的办法了，老老实实的使用同步机制来访问吧。

摘要: SpringMVC使用消息转换器HttpMessageConverter实现请求报文和对象、对象和响应报文之间的自动转换

概述

在SpringMVC中，可以使用@RequestBody和@ResponseBody两个注解，分别完成请求报文到对象和对象到响应报文的转换，底层这种灵活的消息转换机制，就是Spring3.x中新引入的HttpMessageConverter即消息转换器机制。

Http请求的抽象

还是回到请求-响应，也就是解析请求体，然后返回响应报文这个最基本的Http请求过程中来。我们知道，在servlet标准中，可以用javax.servlet.ServletRequest接口中的以下方法：

1

public ServletInputStream getInputStream() throws IOException;

来得到一个ServletInputStream。这个ServletInputStream中，可以读取到一个原始请求报文的所有内容。同样的，在javax.servlet.ServletResponse接口中，可以用以下方法：

1

public ServletOutputStream getOutputStream() throws IOException;

来得到一个ServletOutputStream，这个ServletOutputSteam，继承自java中的OutputStream，可以让你输出Http的响应报文内容。

我们知道，Http请求和响应报文本质上都是一串字符串，当请求报文来到java世界，它会被封装成为一个ServletInputStream的输入流，供我们读取报文。响应报文则是通过一个ServletOutputStream的输出流，来输出响应报文。

我们从流中，只能读取到原始的字符串报文，同样，我们往输出流中，也只能写原始的字符。而在java世界中，处理业务逻辑，都是以一个个有业务意义的对象为处理维度的，那么在报文到达SpringMVC和从SpringMVC出去，都存在一个字符串到java对象的阻抗问题。这一过程，不可能由开发者手工转换。我们知道，在Struts2中，采用了OGNL来应对这个问题，而在SpringMVC中，它是HttpMessageConverter机制。我们先来看两个接口。

HttpInputMessage

这个类是SpringMVC内部对一次Http请求报文的抽象，在HttpMessageConverter的read()方法中，有一个HttpInputMessage的形参，它正是SpringMVC的消息转换器所作用的受体“请求消息”的内部抽象，消息转换器从“请求消息”中按照规则提取消息，转换为方法形参中声明的对象。

1
2
3
4
5
6
7
8
9
10

package org.springframework.http;
import java.io.IOException;
import java.io.InputStream;
public interface HttpInputMessage extends HttpMessage {
    InputStream getBody() throws IOException;
}

HttpOutputMessage

这个类是SpringMVC内部对一次Http响应报文的抽象，在HttpMessageConverter的write()方法中，有一个HttpOutputMessage的形参，它正是SpringMVC的消息转换器所作用的受体“响应消息”的内部抽象，消息转换器将“响应消息”按照一定的规则写到响应报文中。

1
2
3
4
5
6
7
8
9
10

package org.springframework.http;
import java.io.IOException;
import java.io.OutputStream;
public interface HttpOutputMessage extends HttpMessage {
    OutputStream getBody() throws IOException;
}

HttpMessageConverter

对消息转换器最高层次的接口抽象，描述了一个消息转换器的一般特征，我们可以从这个接口中定义的方法，来领悟Spring3.x的设计者对这一机制的思考过程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

package org.springframework.http.converter;
import java.io.IOException;
import java.util.List;
import org.springframework.http.HttpInputMessage;
import org.springframework.http.HttpOutputMessage;
import org.springframework.http.MediaType;
public interface HttpMessageConverter<T> {
    boolean canRead(Class<?> clazz, MediaType mediaType);
    boolean canWrite(Class<?> clazz, MediaType mediaType);
    List<MediaType> getSupportedMediaTypes();
    T read(Class<? extends T> clazz, HttpInputMessage inputMessage)
            throws IOException, HttpMessageNotReadableException;
    void write(T t, MediaType contentType, HttpOutputMessage outputMessage)
            throws IOException, HttpMessageNotWritableException;
}

HttpMessageConverter接口的定义出现了成对的canRead()，read()和canWrite()，write()方法，MediaType是对请求的Media Type属性的封装。举个例子，当我们声明了下面这个处理方法。

1
2
3
4

@RequestMapping(value="/string", method=RequestMethod.POST)
public @ResponseBody String readString(@RequestBody String string) {
    return "Read string '" + string + "'";
}

在SpringMVC进入readString方法前，会根据@RequestBody注解选择适当的HttpMessageConverter实现类来将请求参数解析到string变量中，具体来说是使用了StringHttpMessageConverter类，它的canRead()方法返回true，然后它的read()方法会从请求中读出请求参数，绑定到readString()方法的string变量中。

当SpringMVC执行readString方法后，由于返回值标识了@ResponseBody，SpringMVC将使用StringHttpMessageConverter的write()方法，将结果作为String值写入响应报文，当然，此时canWrite()方法返回true。

我们可以用下面的图，简单描述一下这个过程。

RequestResponseBodyMethodProcessor

将上述过程集中描述的一个类是org.springframework.web.servlet.mvc.method.annotation.RequestResponseBodyMethodProcessor，这个类同时实现了HandlerMethodArgumentResolver和HandlerMethodReturnValueHandler两个接口。前者是将请求报文绑定到处理方法形参的策略接口，后者则是对处理方法返回值进行处理的策略接口。两个接口的源码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package org.springframework.web.method.support;
import org.springframework.core.MethodParameter;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.support.WebDataBinderFactory;
import org.springframework.web.context.request.NativeWebRequest;
public interface HandlerMethodArgumentResolver {
    boolean supportsParameter(MethodParameter parameter);
    Object resolveArgument(MethodParameter parameter,
                           ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest,
                           WebDataBinderFactory binderFactory) throws Exception;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package org.springframework.web.method.support;
import org.springframework.core.MethodParameter;
import org.springframework.web.context.request.NativeWebRequest;
public interface HandlerMethodReturnValueHandler {
    boolean supportsReturnType(MethodParameter returnType);
    void handleReturnValue(Object returnValue,
                           MethodParameter returnType,
                           ModelAndViewContainer mavContainer,
                           NativeWebRequest webRequest) throws Exception;
}

RequestResponseBodyMethodProcessor这个类，同时充当了方法参数解析和返回值处理两种角色。我们从它的源码中，可以找到上面两个接口的方法实现。

对HandlerMethodArgumentResolver接口的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public boolean supportsParameter(MethodParameter parameter) {
    return parameter.hasParameterAnnotation(RequestBody.class);
}
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
        NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
    Object argument = readWithMessageConverters(webRequest, parameter, parameter.getGenericParameterType());
    String name = Conventions.getVariableNameForParameter(parameter);
    WebDataBinder binder = binderFactory.createBinder(webRequest, argument, name);
    if (argument != null) {
        validate(binder, parameter);
    }
    mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
    return argument;
}

对HandlerMethodReturnValueHandler接口的实现

1
2
3
4
5
6
7
8
9
10
11
12
13

public boolean supportsReturnType(MethodParameter returnType) {
    return returnType.getMethodAnnotation(ResponseBody.class) != null;
}
    public void handleReturnValue(Object returnValue, MethodParameter returnType,
        ModelAndViewContainer mavContainer, NativeWebRequest webRequest)
        throws IOException, HttpMediaTypeNotAcceptableException {
    mavContainer.setRequestHandled(true);
    if (returnValue != null) {
        writeWithMessageConverters(returnValue, returnType, webRequest);
    }
}

看完上面的代码，整个HttpMessageConverter消息转换的脉络已经非常清晰。因为两个接口的实现，分别是以是否有@RequestBody和@ResponseBody为条件，然后分别调用HttpMessageConverter来进行消息的读写。