包括：
    “>> 右移”；“<< 左移”；“>>> 无符号右移”

例子：
-5>>3=-1
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1111 1111
其结果与 Math.floor((double)-5/(2*2*2)) 完全相同。

-5<<3=-40
1111 1111 1111 1111 1111 1111 1111 1011
1111 1111 1111 1111 1111 1111 1101 1000
其结果与 -5*2*2*2 完全相同。

5>>3=0
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0000
其结果与 5/(2*2*2) 完全相同。

5<<3=40
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0010 1000
其结果与 5*2*2*2 完全相同。

-5>>>3=536870911     
1111 1111 1111 1111 1111 1111 1111 1011
0001 1111 1111 1111 1111 1111 1111 1111

无论正数、负数，它们的右移、左移、无符号右移 32 位都是其本身，比如 -5<<32=-5、-5>>32=-5、-5>>>32=-5。
一个有趣的现象是，把 1 左移 31 位再右移 31 位，其结果为 -1。
0000 0000 0000 0000 0000 0000 0000 0001
1000 0000 0000 0000 0000 0000 0000 0000
1111 1111 1111 1111 1111 1111 1111 1111

位逻辑运算符

    包括：
    & 与；| 或；~ 非（也叫做求反）；^ 异或

    “& 与”、“| 或”、“~ 非”是基本逻辑运算，由此可以演变出“与非”、“或非”、“与或非”复合逻辑运算。“^ 异或”是一种特殊的逻辑运算，对它求反可以得到“同或”，所以“同或”逻辑也叫“异或非”逻辑。

例子：
5&3=1
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0001

-5&3=1
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0011

5|3=7
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0111

-5|3=-5
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0011
1111 1111 1111 1111 1111 1111 1111 1011

~5=-6
0000 0000 0000 0000 0000 0000 0000 0101
1111 1111 1111 1111 1111 1111 1111 1010

~-5=4
1111 1111 1111 1111 1111 1111 1111 1011
0000 0000 0000 0000 0000 0000 0000 0100

5^3=6
0000 0000 0000 0000 0000 0000 0000 0101
0000 0000 0000 0000 0000 0000 0000 0011
0000 0000 0000 0000 0000 0000 0000 0110

出处：JDON.COM

Java的事件模式是动态响应系统重要的基础，在图形界面领域的事件模式已经有很多文章介绍，但是在服务器端我们会碰到更多的事件模式，这里本人试图总结一下：

　　事件直接驱动模式

　　事件模式的第一个要求就是性能的要求，需要直接而且快，Command模式是必须经常使用的，主要适合于迅速处理 前台的命令，Command模式往往是系统架构的重要部分，也是流程控制的主要模式。

　　Command模式经常Java的Reflect一起使用，因为系统的事件处理系统是处于动态变化的，随着功能要求扩展，就可能有动态变化事件 处理响应系统，以Struts中action为例，我们知道，Structs的一个主要配置文件是struts-config.xml 如下：

　　它实际是个command和event的映射关系，通过这个配置文件，运行时动态装载相应的Action，完成Command模式， 我们检查LoginAction代码，就可以看出Command模式的基本特征：

　　很明显，典型的Command模式需要有一个接口.接口中有一个统一的方法，这里统一的方法就是execute;

　　比如我们有个实时系统，客户段向服务器发出不同编码代号，意味着不同的请求，不同的请求有不同的Handler进行 处理，Handler接口是:

　　不同性质的处理过程继承这个Handler接口，如负责进入系统的处理过程

　　调用Handler时是:

　　以上是常用的一个事件驱动模式。它的特点是靠一个事件直接启动对应的事件处理器。

　　Chain of Responsibility职责链模式也应该属于这类，当事件到达后，让这个事件在我们提供的一批处理器中逐个挑选适合的处理器进行处理，这个模式缺点 是显然的，性能丧失在逐个挑选 上，一般不推荐使用，这个模式适合在我们无法预知发生的事件内容时使用，因为不知道发生事件的具体情况， 我们就无法在程序运行前事先为其指派相应的处理器，只能靠运行时，事件自己去摸索“撞运气”。

监控式事件模式

　　监控式事件模式就不同于事件直接驱动模式，它是借助第三者来监控和触发事件，这类事件的特点是： 有一个观察者置身事外在定期独立运行着，我们将我们要监听的事件向这个观察者注册，这样观察者就 代替我们来监听这个事件，应用客户端通过观察者来获得事件状况。

　　应用客户端有三种与观察者交互的方式：1.直接融合 2.推方式 3.拉方式。

　　直接融合就是说应用客户端自己就是观察者，两者融合，这样无疑应用客户端获得的触发时间是最快的。

　　推方式就是观察者一旦侦测到事件发生，立即将事件Push推到应用客户端；拉方式类似收取邮件，应用客户端在需要时才从观察者拉取事件。

　　JDK 1.4的None Blocking I/O是监控式事件模式的典型实现，Selector显然是一个监控I/O的第三者，当有外部事件进来，通过 调用Slector.select方法可以获得外部事件，从而进行处理，可参考我的本栏文章。

　　监控式事件模式适合使用在触发性质的场合，比如数据库后端触发器 界面触发 I/O触发 状态改变触发等。

　　我们以一个信件触发为例，这其实是个Observer应用例子:

　　比如用户提请服务器计算一个数据，如果用户同时要求将计算结果向自己信箱发一封，那么我们看如何设计？按照通常思维，这是一个次序问题，先在内 存中计算数据，然后将结果发送到他的信箱，最后返回结果到用户端，我们知道信件的发送是耗时的，因此，有可能网络的原因造成信件发送很慢，这是用户就一直 等不到他的计算结果，很显然，我们使用监控式事件模式来解决，让发信的事件由监控者去完成，只要需要时触发就可以了：

　　我们再来看监控观察者代码是如何写的？

　　这样服务器在执行compute方法时，就没有发送邮件的等待，一直接继续执行。

　　监控式事件模式和事件直接驱动模式可以在一个系统一起使用，外界信号通过事件直接驱动模式启动系统处理模块， 系统处理模块处理过程中，可以通过监控式事件模式来触发其它后台任务。这样一个架构非常适合实时处理系统。

　　既然事件处理模式是众多应用系统的基本模式，那么应该可以形成一个框架标准，JMX的notification Model就是这样一个架构设计。

　　JMX Notification Model

　　我们知道，JMX是提供了一种对MBean资源执行控制和配 置的管理机制，但这只是复杂的，分布式的系统中的一部分， 还有需要资源能够感应状态改变或者特定事件变化的机制，这就是JMX Notification Model。 在JMX Notification Model中均可以实现"事件直接驱动模式"和"监控式事件模式"，这取决于你的应用需求。

　　JMX Notification Model允许MBean通过调用notifications广播事件，接受者只要注册为一个listerner， JMX的 MBean notification model 将会激活这个listerner注册一次，然后将一直接受到 来自广播者发出的各种事件。

　　事件模式有三个角色，第一个是事件发出者producer 然后是事件接受者Consumer,第三个 是要传输的事件。JMX notification model也是这样分别依靠下列组件来实现这三个角色：

　　A. NotificationBroadcaster接口, 事件广播发出者， 这个接口允许监听者在需要发出的notification中注册他们感兴趣的事件。

　　B. 通用事件(Notification)，这是我们要传输的事件。 Notification事件能被直接使用，也能成为子类，这些都依赖于随同事件传输的信息。 通过使用通用事件类型，监听者将能接受来自广播者所有类型的事件。
　　
　　C. NotificationListener接口, 事件监听者或者接受者， 用于接受来自广播者的任何notification信号。

　　D. NotificationFilter接口, 这个接口为notification的监听者提供一个对发出事件的过滤器。

　　E. NotificationEmitter 接口, 扩展了NotificationBroadcaster接口，当删除监听者时允许更多的控制功能。

　　只要是MBean，就既可以成为notification的发布广播者，也可以成为notification的监听者接受者，或者同时两者都可以。

　　Attribute Change Notifications

　　Attribute Change Notifications是一种特殊的notification, 任何时候MBean属性attribute 被修改，外界能够被通知到。

　　在JMX架构中，MBean能够在属性attribute变化发生时，发出通知，关于诊断属性变化的机制以及触发 通知事件并不属于JMX规定部分，每个MBean可以有自己独立的实现方式。

　　Timer Service

　　Timer Service触发器是在规定的日期和事件发出通知，它能够一一个恒定的间隙不断重复发出通知， 通知可以发往所有注册为接受timer通知的对象，Timer Service也是一个可管理的MBean，允许应用系统设置 一个可配置的调度程度。

　　Monitoring

　　通过使用monitoring service，一个或多个MBean属性将按规定间隔时间被监视， 对于被观察的Mbean,监视器monitor将从它上面获得一个值，叫derived gauge，这个derived gauge可以是 被观察属性的原值，也可以是一个数字性属性连续被观察值之差。

　　当derived gauge值满足一系列条件时，每个monitor server将会发出一个特定类型的通知。 这些条件都是在monitor被初始化时设定的，也可以通过monitor MBean的管理接口动态设定。

　　根据MBean内部属性值类型有三种monitor:

　　A.CounterMonitor - 使用Java的整数类型来观察属性，有一个行为特征：

　　　a. 总是大于或等于零.

　　　b. 能自增.

　　　c. 能回滚.

　　B.GaugeMonitor - 使用java的整数或浮点类型观察属性。象gauge(测量仪器) 要么上升　要么下降减少。

　　C StringMonitor - 使用String类型观察属性.

　　事件处理架构

　　JMS是基于Socket的一种消息处理框架，原理类似于监控式事件模式，但是JMS已经把这种模式上升到架构的高度。不同JVM间也依靠JMS消息可以实现事件系统（注意是系统，不简单是一个小事件了）的触发和激活。

　　

　　从上面JMS的架构图可以看出事件三个角色Producer和Consumer以及事件信息本身Message．JMS就是在Producer和Consumer之间建立一个连接Connection．

　　JMS可实现同步或异步的事件触发机制，分别是通过Poin to Point(拉方式)和Pubilsh/Subscibe(推方式)具体完成，在分布式计算环境中，异步机制是非常重要，可以起到解耦作用，因为分布环境 中单点错误或通讯问题是经常发生的，整个分布式系统不能总是依靠同步机制来可靠地传递事件或notification．

　　由此可见，事件处理模式从Java诸多架构到我们具体应用程序，随处可见，根据不同的应用需求选择不同的事件处理模式，才能真正挖掘Java的潜在性能。

问题的源头

• 集合：对象的容器与数据结构

• 无序集、有序集、映射

JCF的全家福

    好啦好啦，这些我们都知道，又不是在上数学课，说了这么多废话，怎么还没扯到正题上来？JCF的影子我还没看见呢！列位看官别急，这就给您道来。其实上面的概念对理解JCF非常重要。
    JCF是个颇有点规模的家族，看看它的类层次关系图就知道了，下面这张图（图1）摘自著名的Thinking in Java：


                                            图1

    哇，这么多接口和类，真有点让人无从下手的感觉。其实我们真正需要记住的只是这么一个超超easy的结构（图2）：


                                           图2

    这张图看起来舒服多了吧？但它又能说明什么问题呢？它怎么就能够把握整个JCF呢？我们把Collection接口置于最顶上，意思是想说：Collection其实是整个JCF家族中的“祖宗”，几乎所有的JCF成员都源自该接口，或者和它有密切的关系，Collection提供关于集合的一些通用操作的接口，包括插入（add()方法）、删除（remove()方法）、判断一个元素是不是其成员（contains()方法）、遍历（iterator()方法）等等。注意了，前面的“废话”在这里将得到体现：Set接口体现的是“无序集”的概念，它是不允许有重复元素出现的；List接口代表“有序集”；而Map接口则是“映射”（在早期的Java版本中并不叫Map，我们在后面会看到），其实Map.Entry接口就是代表一个“元素对”我们可以通过Map的entrySet() 方法得到这样一个由“元素对”组成的Set对象。我们注意到Set和List都是从“祖宗”Collection派生的，而Map不是，毕竟对一对元素的 操作与对单个元素的操作还是有区别的，但是如果你仔细对照一下Collection和Map的源代码，以及它们的直接后代AbstractCollection和AbstractMap的源代码，你将会发现很多相似的地方，所以我们仍然可以把Map看成是和Collection有着血缘关系的接口，而和Set，List一起处于并列的位置。
    有了“无序集”，“有序集”和“映射”，我们就可以定义各种各样的抽象数据结构了，譬如图1所示的向量，链表，堆栈，哈希表，平衡二叉树等。但我们需要记住的，仅仅是图2，置于其它的成员，在用到的时候查一下API手册不就行了？不过一般初学者还是比较容易用到一些类，像Vector、ArrayList、HashMap，我在这里列了一张表，显示了常见的JCF成员及其关系：

     可能有的概念您还不是太了解，譬如什么叫“历史集合”，Hashtable、HashMap、TreeMap三者之间有什么区别和联系，怎样实现对一个特定集合的快速遍历、元素查找或者排序，没关系，我们在下面将逐一进行研究。

细节考虑：目标与效率

    有了JCF的层次还不够，重要的是对集合所容纳的对象的具体操作，以前我们学数据结构的时候可能老师总会让你计算一个算法的时间复杂度，可能你会对这个O(f(n))很不耐烦，但事实上算法效率是一个重要的因素。

1. 侧重点：遍历 vs. 查找

     对集合的有两个主要的应用：我需要知道集合有哪些元素；根据条件找到一个特定的元素。在算法上通常称为“遍历”和“查找”。不要以为我们生活中不常用哦！ 譬如CCTV的“幸运52”里面，李咏让参赛者报出一款PDA的准确价位，他会怎么做？“2000”“高了”“1000”“低了”“1500”“低 了”……直到答对为止。可能有很多人都会选择这个策略，无论他是不是计算机专业出身的，也不知道他是不是了解“数据结构”和“折半查找”，更不用说他是不 是知道还有比在无初始代价下O(log n)的时间复杂度更快的算法了，但我们经常会自然而然地用这样的方法，这和一个人的行业无关，除非这个人的rp超强，呵呵……
    又讲了一堆 题外话了，遍历和修改似乎是一对矛盾，一个可以高效率插入删除元素的数据结构通常遍历的性能并不是最优。于是JCF在这里根据用户的目标实现了两种定制的 数据结构：哈希表（包括HashSet和HashMap）和平衡二叉树（包括TreeSet和TreeMap）。由于可排序性是一种独特的要求，所以引入 了SortedSet和SortedMap，它们分别是AbstractSet和AbstractMap的子接口，而TreeSet和TreeMap又分 别是他们的一种实现。熟悉数据结构的人可能比较了解，哈希表在进行插入、删除、查找这样的操作是很快的，其时间复杂度是常数级O(1)；平衡二叉树虽然插 入、删除操作比较麻烦（需要O(log n)的代价），但进行遍历和排序却很快。选择完全在于用户的侧重点，但由于类型转换的方便性，通常我们用哈希表构造一个集合以后，再把它转换成相应的树集 进行遍历，以获得较好的效果。

Set set1 = newHashSet(); set1.add(elem1);// 通过插入元素构造集合 set1.add(elem2); set1.add(elem3); Set set2 = newTreeSet(set); Iterator all = set2.iterator(); while (all.hasNext()) {// 遍历集合 all.next(); ... }

2. 历史实现 vs. 新实现

3. 同步 vs. 不同步

4. 容易遗忘的工具： Collections 和 Arrays

5. 泛型

小结

     我这里走马观花一样把JCF的一些主要概念罗嗦了一下，Java的老手们可能比较厌烦，新手们可能更觉得像回顾了一下高中的数学课和大学的数据结构，呵 呵。这只是一个小小的例子，可见基础知识对现实当中的应用还是蛮有指导意义的。大师们看数学，觉得那是很唯美很艺术的一样东西，西方一直都把数学区别于其 它自然科学，而认为它更靠近于哲学，像我等这样整天还在为找工作烦得要死的俗人还是没法入道啊，sigh……

参考资料

• IBM developerWorks教程： Java 集合框架
• J2SE Documentation: The Collections Framework
• The Java Tutorial
• JCF API

 jungleford如是说

    用惯了VC的人刚接触Java大概很不习惯代码的调试，的确，在M$的大部分IDE都做得相当出色，包括像VJ++这样一直被Java程序员称为是“垃圾”的类库（记得以前在瀚海星云的Java版提有关VJ问题的人是有可能被封的，^_^），它的开发工具在调试上都相当容易。Java也有命令行方式的调试和IDE的调试，但现在的像JB这 样的玩意又是个庞然大物，低配置的机器可能就是个奢望，不像VC那样。怎么办呢，高手们说，“我的jdb用得贼熟练”，那我会报以景仰的目光，像我这样的 菜鸟基本上就没使过jdb，还是老老实实在代码里面System.out.println(...)。直到1996年一个叫做“欧洲安全电子市场” （E.U. SEMPER）的项目启动，“调试”不再是一件“体力活”，而是一种软件设计的艺术，这个项目组开发的日志管理接口后来成为ApacheJakarta项目中的一员，它就是现在我们所熟悉的log4j。下面的文字将概要介绍与Java日志记录相关的一些技术，目的不是让您放弃老土的System.out.println(...)，而是说，在Java的世界里可以有许多种选择，你今天觉得掌握了一件高级武器，明天可能就是“过时”的了，呵呵。

始祖：System.out.println(...)

    为什么还是要一再提到它？毕竟我们的习惯不是那么容易改变的，而且System.out（别忘了还有System.err）是一个直接和控制台打交道的PrintStream对象，是终端显示的基础，高级的Logger要在终端显示日志内容，就必然会用到这个。一个小规模的程序调试，恰当地使用System.out.println(...)我认为仍然是一种最方便最有效的方法，所以我们仍把它放在最开始，以示不能“数典忘祖” :)

不常用的关键字：assert

    assert对多数人来讲可能还比较陌生，它也是一个调试工具，好像是J2SE 1.4才加进来的东东，一种常见的用法是：

assert (布尔表达式);

    当表达式为true时没有任何反映，如果为false系统将会抛出一个AssertionError。如果你要使用assert，在编译时必须加上“-source 1.4”的选项，在运行时则要加上“-ea”选项。

后生可畏：Java Logging API一瞥

    System.out.println(...)对于较高要求的用户是远远不够的，它还不是一个日志系统，一个比较完善的日志系统应当有输出媒介、优先级、格式化、日志过滤、日志管理、参数配置等功能。伴随J2SE 1.4一起发布的Java日志包java.util.logging适时地满足了我们的初步需求，在程序中按一定格式显示和记录丰富的调试信息已经是一件相当easy的事情。

1. 日志记录器：Logger
    Logger是 一个直接面向用户的日志功能调用接口，从用户的角度上看，它完成大部分日志记录工作，通常你得到一个Logger对象，只需要使用一些简单方法，譬如 info，warning，log，logp，logrb等就能完成任务，简单到和System.out.println(...)一样只用一条语句，但 后台可能在向控制台，向文件，向数据库，甚至向网络同时输出该信息，而这个过程对用户是完全透明的。
    在使用Logger之前，首先需要通过getLogger()或getAnonymousLogger()静态方法得到一个Logger对象（想想看，这里是不是设计模式当中的“工厂方法”的一个实实在在的应用？可以参考一下Logger的源代码，你就明白LogManager是“工厂类”而Logger是“产品类”，凡事都要学以致用嘛，呵呵）。这里我们需要了解的是Logger的“名字空间”（namespace） 的概念：通常我们调试时需要清楚地知道某个变量是出现在什么位置，精确到哪个类的哪个方法，namespace就是这么个用处。我们用getLogger ()得到Logger时需要指定这个Logger的名字空间，通常是一个包名，譬如“com.jungleford.test”等，如果是指定了 namespace，那么将在一个全局对象LogManager中注册这个namespace，Logger会基于namespace形成层次关系，譬如 namespace为“com.jungleford”的Logger就是namespace为“com.jungleford.test”的 Logger的父，后者调用getParent() 方法将返回前者，如果当前没有namespace为“com.jungleford”的Logger，则查找namespace为“com”的 Logger，要是按照这个链找不到就返回根Logger，其namespace为""，根Logger的父是null。从理论上说，这个 namespace可以是任意的，通常我们是按所调试的对象来定，但如果你是使用getAnonymousLogger()方法产生的Logger，那它 就没有namespace，这个“匿名Logger”的父是根Logger。
    得到一个Logger对象后就可以记录日志了，下面是一些常用的方法：

finest、finer、fine、info、config、warning、severe：简洁的方法，输出的日志为指定的级别。关于日志级别我们在后面将会详细谈到。 log：不仅可以指定消息和级别，还可以带一些参数，甚至可以直接是一个LogRecord对象（这些参数是LogRecord对象的重要组成部分）。 logp：更加精细了，不但具有log方法的功能，还可以不使用当前的namespace，定义新的类名和方法名。 entering、exiting：这两个方法在调试的时候特别管用，用来观察一个变量变化的情况，就如同我们在VC的调试状态下watch一个变量，然后按F10，呵呵。

2. 输出媒介控制：Handler
    日志的意义在于它可以以多种形式输出，尤其是像文件这样可以长久保存的媒介，这是System.out.println(...)所无法办到的。Logging API的Handler类提供了一个处理日志记录（LogRecord，它是对一条日志消息的封装对象）的接口，包括几个已实现的API：

ConsoleHandler：向控制台输出。 FileHandler：向文件输出。 SocketHandler：向网络输出。

    这三个输出控制器都是StreamHandler的子类，另外Handler还有一个MemoryHandler的子类，它有特殊的用处，我们在后面将会看到。在程序启动时默认的Handler是ConsoleHandler，不过这个是可以配置的，下面会谈到logging配置文件的问题。
    此外用户还可以定制自己输出控制器，继承Handler即可，通常只需要实现Handler中三个未定义的抽象方法：

publish：主要方法，把日志记录写入你需要的媒介。 flush：清除缓冲区并保存数据。 close：关闭控制器。

    通过重写以上三个方法我们可以很容易就实现一个把日志写入数据库的控制器。

3. 自定义输出格式：Formatter
    除了可以指定输出媒介之外，我们可能还希望有多种输出格式，譬如可以是普通文本、HTML表格、XML等等，以满足不同的查看需求。Logging API中的Formatter就是这样一个提供日志记录格式化方法接口的类。默认提供了两种Formatter：

SimpleFormatter：标准日志格式，就是我们通常在启动一些诸如Tomcat、JBoss之类的服务器的时候经常能在控制台下看到的那种形式，就像这样：

2004-12-20 23:08:52 org.apache.coyote.http11.Http11Protocol init 信息: Initializing Coyote HTTP/1.1 on http-8080 2004-12-20 23:08:56 org.apache.coyote.http11.Http11Protocol init 信息: Initializing Coyote HTTP/1.1 on http-8443

XMLFormatter：XML形式的日志格式，你的Logger如果add了一个new XMLFormatter()，那么在控制台下就会看到下面这样的形式，不过更常用的是使用上面介绍的FileHandler输出到XML文件中：

<?xml version="1.0" encoding="GBK" standalone="no"?> <!DOCTYPE log SYSTEM "logger.dtd"> <log> <record>   <date>2004-12-20T23:47:56</date>   <millis>1103557676224</millis>   <sequence>0</sequence>   <logger>Test</logger>   <level>WARNING</level>   <class>Test</class>   <method>main</method>   <thread>10</thread>   <message>warning message</message> </record>

    与Handler类似，我们也可以编写自己的格式化处理器，譬如API里没有将日志输出为我们可通过浏览器查看的HTML表格形式的Formatter，我们只需要重写3个方法：

format：格式化LogRecord中包含的信息。 getHead：输出信息的头部。 getTail：输出信息的尾部。

4. 定义日志级别：Level
    大家可能都知道Windows的“事件查看器”，里面有三种事件类型：“信息”、“警告”、“错误”。这其实就是日志级别的一种描述。Java日志级别用Level类表示，一个日志级别对应的是一个整数值，范围和整型值的范围是一致的，该整数值愈大，说明警戒级别愈高。Level有9个内置的级别，分别是：

类型	对应的整数
OFF	最大整数（Integer.MAX_VALUE）
SEVERE	1000
WARNING	900
INFO	800
CONFIG	700
FINE	500
FINER	400
FINEST	300
ALL	最小整数（Integer.MIN_VALUE）

    你也可以定义自己的日志级别，但要注意的是，不是直接创建Level的对象（因为它的构造函数是protected的），而是通过继承Level的方式，譬如：

class AlertLevel extends java.util.logging.Level {   public AlertLevel()   {     super("ALERT", 950);   } } ... Logger logger = Logger.getAnonymousLogger(); logger.log(new AlertLevel(), "A dangerous action!");

    上面定义了一个高于WARNING但低于SEVERE的日志级别。
    于是可能有朋友会兴冲冲地用以下的语句来记录一个事件：

Logger logger = Logger.getAnonymousLogger(); logger.fine("Everything seems ok."); //或者是 //logger.log(Level.FINE, "Everything seems ok.");

    但是一程序运行，奇怪了，怎么没有打印出任何消息呢？下一小节我们就来谈这个问题。

5. 日志过滤器：Filter
     所谓过滤器是控制哪些日志该输出哪些不该输出的一种组件。上面你写的那条日志没有能在控制台显示出来，是因为logging API预先设定的缺省级别是INFO，也就是说只有级别不低于INFO（即其整数值不小于800）的日志才会被输出，这个就是Filter的功能。所以我 们可以看到SEVERE、WARNING、INFO以及上面我们定义的ALERT消息，但看不到FINE、FINER和FINEST消息。当然，你尽可以 用Logger的setLevel方法或者修改配置文件的方法（什么是配置文件，我们后面将会看到）来重新定义Logger输出的最低级别。
    Filter不仅仅可以按日志级别过滤，你也可以定义自己的Filter，实现其中的isLoggable方法，随便按照LogRecord携带的任何信息进行过滤，譬如（顺便复习一下匿名类，呵呵）：

Logger logger = Logger.getAnonymousLogger(); logger.setFilter(newFilter() {   publicboolean isLoggable(LogRecord rec)   {     //从LogRecord里得到过滤信息   } });

6. 预定义参数
    LogManager是一个实现了Singleton模式的全局对象（由于是一个唯一的对象，LogManager需要是线程安全的），它管理着程序启动以后所有已注册（包层次）或匿名的Logger，以及相关配置信息。这里的配置信息通常是从<JAVA_HOME>\jre\lib\logging.properties文件得到的。logging.properties对于logging API来说是一个很重要的文件，它的内容一般是：

############################################################ # Default Logging Configuration File # # You can use a different file by specifying a filename # with the java.util.logging.config.file system property. # For example java -Djava.util.logging.config.file=myfile ############################################################ ############################################################ # Global properties ############################################################ # "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler # To also add the FileHandler, use the following line instead. #handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler # Default global logging level. # This specifies which kinds of events are logged across # all loggers. For any given facility this global level # can be overriden by a facility specific level # Note that the ConsoleHandler also has a separate level # setting to limit messages printed to the console. .level= INFO ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################ # default file output is in user's home directory. java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. # Provides extra control for each logger. ############################################################ # For example, set the com.xyz.foo logger to only log SEVERE # messages: com.xyz.foo.level = SEVERE

    你可以通过修改这个配置文件来改变运行时Logger的行为，譬如：.level定义的是上面所说的默认输出的最低日志级别；XXXHandler相关属性定义了各种输出媒介等等。
    这里比较有意思的是关于日志文件，也就是FileHandler，当然，你可以在程序中创建一个FileHandler，然后添加到logger中：

FileHandler fhd = newFileHandler("%h/java%u.log", 5000, 1, true); fhd.setLevel(Level.ALL); fhd.setFormatter(newXMLFormatter()); logger.addHandler(fhd);

    这段代码等价于上面logging.properties中的文字段：

java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter

    这里的pattern代表用转义字符定义的一个日志文件名：

转义字符串	含义
%t	临时目录
%h	用户目录，即系统属性“user.home”对应的值
%g	一个随机生成的数字，可以重复
%u	一个随机生成的非重复数字

    以上面的“%h/java%u.log”为例，在Windows 2000下代表日志文件可能就是：C:\Documents and Settings\Administrator\javax.log。这里x代表一个不重复的数字，如果是第一次，那么就是java0.log；如果在该目录下已经存在了一个java0.log的文件，那么logger就产生一个java1.log的新的日志文件。
    当然，你可以在别的地方使用自己写的配置文件，不过在启动程序时候需要指定java.logging.config.file属性：

java -Djava.logging.config.file=...

7. 资源与本地化
    Logger里还有个方法叫logrb， 可能初学者不太会用到。如果你安装的JDK是国际版的，那么你将会看到在中文Windows平台下日志输出的INFO、WARNING显示的是“信息”、 “警告”等中文字样。因为logrb是一个和Java i18n/l10n相关的方法，你可以定义自己的“资源包”（Resource Bundle），然后在logrb方法中指定相应的资源名称，那么在输出日志中你就能看到用自己定义的本地语言、时间等显示的信息。如果你对 i18n/l10n感兴趣，可以参考Java Localization文档。


    了解以上组件后，我们回顾一个完整的日志处理的工作过程：
     程序启动日志服务，创建Logger对象，LogManager按照namespace的层次结构组织Logger，在同一个namespace里子 Logger将继承父Logger的属性；同时，LogManager从logging.properties中读取相应的属性对Logger进行初始 化，如果在程序中设置了属性则使用新的配置。当应用程序产生一条日志，Logger将创建一个LogRecord对象，该对象封装了一条日志的全部信息。 Logger需要根据当前设置的Filter来判断这条日志是否需要输出，并将有用的日志传给相应的Handler处理，而Handler根据当前设置的 Formatter和Resource Bundle将日志消息转换成一定的显示格式，然后输出到预定的媒介（控制台、文件等）中去。整个过程大致如图1所示：

图1

    前面我们在介绍Handler的时候提到过一个特殊的类叫MemoryHandler， 这里我们要了解一下“Handler链”的概念，日志在输出之前可能经过多个Handler的处理，MemoryHandler在这种情况下就是一个中间 角色，它维持一个内存中的日志缓冲区，当日志没有填满缓冲区时就将全部日志送到下一个Handler，否则新进来的日志将会覆盖最老的那些日志，因此，使 用MemoryHandler可以维护一定容量的日志，另外，MemoryHandler也可以不需要使用Formatter来进行格式化，从而具有较高 的效率。一个使用Handler链的例子如图2所示：

图2

青出于蓝：Apache Jakarta log4j日志工具包

     应付日常的日志需求，J2SE的Logging API可以说已经做得相当出色了，但追求完美的开发人员可能需要可扩展性更好的专业日志处理工具，log4j正是当前比较流行的一个工具包，它提供更多的 输出媒介、输出格式和配置选择，你会发现原来在J2SE里一些仍需要自己手工构建的功能在log4j当中都已经为你实现了。关于log4j我可能谈得不会 太多，可以看看文后所附的“参考资料”，网上也有很详细的介绍，我在这里做的是一个对比，因为log4j和J2SE 1.4 Logging API的用法是很相似的，一些名称不同的组件你会发现他们所处的地位其实是一样的：

	J2SE 1.4中的类	log4j中的类
日志记录器	Logger	Logger
日志管理器	LogManager	LogManager
日志对象	LogRecord	LoggingEvent
输出媒介控制	Handler	Appender
格式化	Formatter	Layout
级别	Level	Level
过滤器	Filter	Filter

    log4j可以做到更精细更完善的控制，譬如J2SE里没有现成向数据库里写日志的方法，但log4j却有JDBCAppender，它甚至还能向GUI图形界面（LF5Appender，一种以JTree方式显示的层次结构）、Windows NT事件查看器（NTEventLogAppender）、UNIX的syslogd服务（SyslogAppender）、电子邮箱（SMTPAppender）、Telnet终端（TelnetAppender）、JMS消息（JMSAppender） 输出日志，牛吧；J2SE里默认只能用%JAVA_HOME%\jre\lib\logging.properties做配置文件，但log4j却可以在 代码中设置其它路径下的properties文件或XML格式的配置文件。log4j的其它方面同样很丰富，总之，log4j的最大的特点就是“灵活”， 无论是Appender、Layout还是Configurator，你可以把日志轻松地弄成几乎任何你想要的形式。

框架与标准：JSR议案

    从时间顺序上讲，log4j要比J2SE Logging API来得早，很多概念都是log4j先有的，但成为一个标准，则是在JSR 47的形成。可能有人还不太了解JSR，这还要谈到JCP，即“Java Community Process”，它是一个于1998年成立的旨在为Java技术制定民间标准的开放组织，你可以通过http://www.jcp.org/en/participation/membership申 请成为它的付费或免费会员，JCP的主要工作就是制定和发布JSR（Java Specification Requests），JSR对于Java的意义就相当于RFC对于网络技术的意义，由于JCP会员们的集思广益，使得JSR成为Java界的一个重要标 准。JSR 47即“Logging API Specification”，制定了调试和日志框架，J2SE Logging API正是该框架的一个实现。由于种种原因，在JSR 47出来以前，log4j就已经成为一项成熟的技术，使得log4j在选择上占据了一定的优势，但不能因此就说JSR 47是过时的规范，标准总是在发展的嘛！

并不是全部：其它日志处理工具

    除了J2SE Logging API和log4j，日志处理方面还有别的技术：Jakarta的commons组件项目中的JCL（Jakarta Commons Logging）是一个不错的选择，它有点类似于GSS-API（通用安全服务接口）中的思想，其日志服务机制是可以替换的，也就是说既可以用J2SE Logging API也可以用log4j，但JCL对开发人员提供一致的接口，这一点相当重要，组件可重用正是Jakarta Commons项目追求的一个目标；IBM的JLog也是在J2SE Logging API之前推出的一个工具包，但JLog是一个商业产品。
    至于日志API的应用那可就多了，现在哪个大一点的工具或平台不用到日志模块呢？Tomcat、JBoss……

    说了这么多，我们无非需要知道的一件事就是，“调试”也是一门学问。在我们一个劲地用System.out.println(...)而且用得很爽的时候，也应该想想看，如何让这样一条菜鸟语句也能变得人性化和丰富多彩。

参考资料

• Java Logging Documentation
• Java Logging APIs
• J2SE进阶, by www.javaresearch.org
• Short introduction to log4j, by Ceki Gülcü
• log4j APIs
• FAQ about log4j

日志系统是一种不可或缺的跟踪调试工具，特别是在任何无人职守的后台程序以及那些没有跟踪调试环境的系统中有着广泛的应用。 长期以来， 日志系统作为一种应用程序服务，对于跟踪调试、程序状态记录、崩溃数据恢复都有非常现实的意义。这种服务通常以两种方式存在：

1.       日志系统作为服务进程存在。 Windows 中的的事件日志服务就属于这种类型，该类型的日志系统通常通过消息队列机制将所需要记录的日志由日志发送端发送给日志服务。日志发送端和日志保存端通常不在同一进程当中，日志的发送是异步过程。这种日志服务通常用于管理员监控各种系统服务的状态。

2.       日志系统作为系统调用存在。 Java 世界中的日志系统和 Unix 环境下诸多守护进程所使用的日志系统都属于这种类型。日志系统的代码作为系统调用被编译进日志发送端，日志系统的运行和业务代码的运行在同一进程空间。日志的发送多数属于同步过程。这种日志服务由于能够同步反映处系统运行状态，通常用于调试跟踪和崩溃恢复。

本文建立的日志系统基本属于第二种类型，但又有所不同。该日志系统将利用 Java 线程技术实现一个既能够反映统一线程空间中程序运行状态的同步日志发送过程，又能够提供快速的日志记录服务，还能够提供灵活的日志格式配置和过滤机制。

1.1         系统调试的误区

在控制台环境上调试 Java 程序时，此时往控制台或者文本文件输出一段文字是查看程序运行状态最简单的做法，但这种方式并不能解决全部的问题。有时候，对于一个我们无法实时查看系统输出的系统或者一个确实需要保留我们输出信息的系统，良好的日志系统显得相当必要。

因此，不能随意的输出各种不规范的调试信息，这些随意输出的信息是不可控的，难以清除，可能为后台监控、错误排除和错误恢复带来相当大的阻力。

1.2         日志系统框架的基本功能

一个完备的日志系统框架通常应当包括如下基本特性：

n         所输出的日志拥有自己的分类。这样在调试时便于针对不同系统的不同模块进行查询，从而快速定位到发生日志事件的代码。

n         日志按照某种标准分成不同级别。分级以后的日志，可以用于同一分类下的日志筛选。

n         支持多线程。日志系统通常会在多线程环境中使用，特别是在 Java 系统当中，因此作为一种系统资源，日志系统应当保证是线程安全的。

n         支持不同的记录媒介。不同的工程项目往往对日志系统的记录媒介要求不同，因此日志系统必须提供必要的开发接口，以保证能够比较容易的更换记录介质。

n         高性能。日志系统通常要提供高速的日志记录功能以应对大系统下大请求流量下系统的正常运转。

n         稳定性。日志系统必须是保持高度的稳定性，不能因为日志系统内部错误导致主要业务代码的崩溃。

1.3         常用日志系统简介

在 Java 世界中，以下三种日志框架比较优秀：

1)        Log4J

最早的 Java 日志框架之一，由 Apache 基金会发起，提供灵活而强大的日志记录机制。但是其复杂的配置过程和内部概念往往令使用者望而却步。

2)        JDK1.4 Logging Framework

继 Log4J 之后， JDK 标准委员会将 Log4J 的基本思想吸收到 JDK 当中，在 JDK1.4 中发布了第一个日志框架接口，并提供了一个简单实现。

3)        Commons Logging Framwork

该框架同样是 Apache 基金会项目，其出现主要是为了使得 Java 项目能够在 Log4J 和 JDK1.4 l Logging Framework 的使用上随意进行切换，因此该框架提供了统一的调用接口和配置方法。

2          系统设计

由于 Log4J 得到广泛应用，从使用者的角度考虑，本文所设计的框架，采用了部分 Log4J 的接口和概念，但内部实现则完全不同。使用 Java 实现日志框架，关键的技术在于前面提及的日志框架特性的内部实现，特别是：日志的分类和级别、日志分发框架的设计、日志记录器的设计以及在设计中的高性能和高稳定性的考虑。

2.1         系统架构

图 1 ，日志系统结构图

下图 2 使用 UML 类图给出了日志系统的架构：

图 2 ，日志系统框架架构图

       在图 2 给出的架构中， 日志记录器 Logger 是整个日志系统框架的用户使用接口，程序员可以通过该接口记录日志，为了实现对日志进行分类，系统设计允许存在多个 Logger 对象，每一个 Logger 负责一类日志的记录， Logger 类同时实现了对其对象本身的管理。 LoggerLevel 类定义了整个日志系统的级别，在客户端创建和发送日志时，这些级别会被使用到。 Logger 对象在接收到客户端创建和发送的日志消息时，同时将该日志消息包装成日志系统内部所使用的日志对象 LogItem ，日志对象除了发送端所发送的消息以外，还会包装诸如发送端类名、发送事件、发送方法名、发送行号等等。这些额外的消息对于系统的跟踪和调试都非常有价值。包装好的 LogItem 最终被发送给 输出器 ，由这些 输出 器负责将日志信息写入最终媒介， 输出器 的类型和个数均不固定，所有的 输出器 通过 AppenderManager 进行管理，通常通过配置文件即可方便扩展出多个 输出器 。

2.2         日志记录部分的设计

如前文所述，日志记录部分负责接收日志系统客户端发送来的日志消息、日志对象的管理等工作。下面详细描述了日志记录部分的设计要点：

1.         日志记录器的管理

系统通过保持多个 Logger 对象的方式来进行日志记录的分类。每一个 Logger 对象代表一类日志分类。因此， Logger 对象的名称属性是其唯一标识，通过名称属性获取一个 Logger 对象：

Logger logger = Logger.getLogger(“LoggerName”);

一般的，使用类名来作为日志记录器的名称，这样做的好处在于能够尽量减少日志记录器命名之间的冲突（因为 Java 类使用包名），同时能够将日志记录分类得尽可能的精细。因此，假定有一 UserManager 类需要使用日志服务，则更一般的使用方式为：

Logger logger = Logger.getLogger(UserManager.class);

2.         日志分级的实现

按照日志目的不同，将日志的级别由低到高分成五个级别：

DEBUG        - 表示输出的日志为一个调试信息

INFO      - 表示输出的日志是一个系统提示

WARN   - 表示输出的日志是一个警告信息

ERROR - 表示输出的日志是一个系统错误

FATAL    - 表示输出的日志是一个导致系统崩溃严重错误

这些日志级别定义在 LoggerLevel 接口中，被日志记录器 Logger 在内部使用。而对于日志系统客户端则可使用 Logger 类接口对直接调用并输出这些级别的日志， Logger 的这些接口描述如下：

public void debug(String msg);  // 输出调试信息

public void info(String msg);   // 输出系统提示

public void warn(String msg);   // 输出警告信息

public void fatal(String msg);  // 输出系统错误

public void error(String msg);  // 输出严重错误

通过对 Logger 对象上这些接口的调用，直接为日志信息赋予了级别属性，这样为后继的按照不同级别进行输出的工作奠定了基础。

3.         日志对象信息的获取

日志对象上包含了一条日志所具备的所有信息。通常这些信息包括：输出日志的时间、 Java 类、类成员方法、所在行号、日志体、日志级别等等。在 JDK1.4 中可以通过在方法中抛出并且捕获住一个异常，则在捕捉到的异常对象中已经由 JVM 自动填充好了系统调用的堆栈，在 JDK1.4 中则可以使用 java.lang.StackTraceElement 获取到每一个堆栈项的基本信息，通过对日志客户端输出日志方法调用层数的推算，则可以比较容易的获取到 StackTraceElement 对象，从而获取到输出日志时的 Java 类、类成员方法、所在行号等信息。在 JDK1.3 或者更早的版本中，相应的工作则必须通过将异常的堆栈信息输出到字符串中，并分析该字符串格式得到。

2.3         日志 输出部分 的设计

日志输出部分的设计具有一定的难度，在本文设计的日志系统中，日志的输出、多线程的支持、日志系统的扩展性、日志系统的效率等问题都交由日志输出部分进行管理。

1.         日志输出器的继承结构

在日志的输出部分采用了二层结构，即定义了一个抽象的日志输出器（ AbstractLoggerAppender ） , 然后从该抽象类继承出实际的日志输出器。 AbstractLoggerAppender 定义了一系列的对日志进行过滤的方法，而具体输出到存储媒介的方法则是一个抽象方法，由子类实现。在系统中默认实现了控制台输出器和文件输出器两种，其中控制台输出器的实现颇为简单。

2.         文件输出器的内部实现

在日志记录部分的实现中，并没有考虑多线程、高效率等问题，因此文件输出器必须考虑这些问题的处理。在文件输出器内部使用 java.lang.Vector 定 义了一个线程安全的高速缓冲，所有通过日志记录部分分派到文件输出器的日志被直接放置到该高速缓冲当中。同时在文件输出器内部定义一个工作线程，负责定期 将高速缓冲中的内容保存到文件，在保存的过程中同时可以进行日志文件的备份等工作。由于采用了高速缓冲的结构，很显然日志客户端的调用已经不再是一个同步 调用，从而不再会需要等到文件操作后才返回，提高的系统调用的速度。该原理 如图 3 所示：

图 3 ，文件输出器内部结构

2.4         设计难点

通过上述设计，一个具有良好扩展能力的高性能日志系统框架就已经具有了一定的雏形。在设计过程中几个难点问题需要进一步反思。

一、是否整个系统应当采用完全异步的结构，通过类似于消息机制的方式来进行由日志客户端发送日志给日志系统。这种方式可以作为日志系统框架另一种运行方式，在后继设计中加以考虑。

二、在文件输出器中可以看到，目前虽然可以扩展多个日志输出器，但是目前提供的抽象类中仅仅提供了对日志的过滤机制，而没有提供的缓存机制，目前的缓存机制被放在文件输出器中实现，因此在未来的进一步设计中，可以将文件输出器中的缓存机制上移到抽象类当中。

2.5         设计模式

在设计过程中我们特别注意使用了数个经典的设计模式。如： Logger 对象的创建使用了工厂方法模式（ Factory Method ）、由 AbstractLoggerAppender 和 ConsoleAppender 以及 FileAppender 构成了策略模式（ Strategy ），除此以外，还大量使用了单例模式（ Singleton ）。在设计中适当运用设计模式能够加快设计进度、提高设计质量。

3          总结

本文探讨了日志系统的基本特性、实现日志系统的意义、方法和内部结构，并且给出了一种基于 Java 平台的日志系统的详细设计。同时也指出日志系统会向服务化、异步化的方向发展。作为一种方便的跟踪调试、数据恢复工具，应当提倡在适当的环境下对日志系统的使用。

摘要

这个文档资料描述了log4j API，它的独特的特性和设计原理。Log4j是由许多 作者共同参与的开放源代码项目。它允许开发人员以任意的精细程度控制哪些 日志说明被输出。通过使用外部的配置文件，可以在运行时配置它。最好的 是，log4j 开发包很容易上手。注意，它也可能会使一些开发人员着迷。

简 介

几乎每个大的应用程序都有它自己的日志和跟踪程序的API。顺应这一规则，E.U. SEMPER项目组决定编写它自己的程序跟踪API（tracing API）。这开始于1996年早期。经过无数的工作，更改和性能加强，这个API终于成为一个十分受欢迎的Java日志软件包，那就是log4j。这个软件包的发行遵守open source动议认证的Apache Software License。最新的log4j版本包括全部的源代码，类文件和文档资料，可以在 http://logging.apache.org/log4j/找到它们。另外，log4j已经被转换成 C, C++, C#, Perl, Python, Ruby, 和 Eiffel 语言。

把log statements插入到你的代码中是一种排错的低技能办法。这也许是唯一的方法，因为排错工具并不总是可以被使用或者适用于你的程序。对于多线程的应用程序和多数发行的应用程序，通常就是这样的情形。

经验告诉我们logging是开发过程中重要的一环。它具有多种优点。首先，它能精确地提供运行时的上下文(context)。 一旦在程序中加入了Log 代码，它就能自动的生成并输出logging信息而不需要人为的干预。另外，log信息的输出可以被保存到一个固定的地方，以备以后研究。除了在开发过程 中发挥它的作用外，一个性能丰富的日志记录软件包能当作一个审计工具(audit tool)使用。

Brian W. Kernighan 和 Rob Pike 在他们的"The Practice of Programming" 书中这样写到：  "The Practice of Programming"

作为个人的选择，除了得到一大堆程序跟踪信息或一两个变量值以外，我们倾
向於不使用排错器。一个原因是在详细而复杂的数据结构和控制流程中很容易
迷失；我们发现认真思考并在关键处加入自我检查代码和输出指令，比起一步
步看程序要效率高。在日志说明里查找比在明智地放置自我检查代码后的输出
里查找要费时。而决定在哪里放置打印指令要比在日志说明里一步步找到关键
的代码要省时间。更重要的是，自我检查的排错指令和程序并存；而排错
sessions是暂时的。

Logging确实也有它的缺陷。它降低了程序运行的速度。它太冗长，查看时很容易错过。为了减少这些负面影响，log4j 被设计得可靠，高效和灵活。因为，记录日志很少是一个应用程序的主要焦点，log4j API 尽量做到容易被理解和使用。

Loggers, Appenders and Layouts

Log4j 有三个主要组件：loggers, appenders和layouts。这三类组件一起应用，可以让开发人员能够根据日志的类型和级别进行记录，并且能在程序运行时控制log信息输出的格式和往什么地方输出信息。

Logger hierarchy

任何logging API 与简单的System.out.println输出调试信息方法比较，最主要的优点在于它能够关闭一些调试信息输出而不影响其他人的调试。这种能力的实现是假设这些logging空间，也就是所有的可能发生的日志说明空间，可以根据程序开发人员选择的标准进行分类。这一观察以前使得我们选择了category作为这个软件包的中心概念。但是，在log4j 1.2版本以后，Logger类取代了Category类。对于那些熟悉早先版本的log4j的开发人员来说，Logger类只不过是Category类的一个别名。

Loggers是被命名的实体。Logger的名字大小写有区别（case-sensitive），并且它们遵守阶层式的命名规则：

例如，叫做"com.foo"的logger是叫做 "com.foo.Bar"的logger的父辈 。同样地，"java"是"java.util" 的父辈，是"java.util.Vector"的前辈。大多数开发人员都熟悉这种命名方法。  "com.foo"  "com.foo.Bar"  "java"  "java.util"  "java.util.Vector"

根（root）logger 位于logger 阶层的最上层。它在两个方面很特别:

1. 它总是存在的，
2. 不能通过使用它的名字直接得到它。

通过这个类的静态方法Logger.getRootLogger得到它（指RootLogger）。所有其他的loggers是通过静态方法Logger.getLogger来实例化并获取的。这个方法Logger.getLogger把所想要的logger的名字作为参数。 Logger类的一些其它基本方法在下面列出：

package org.apache.log4j; 
public class Logger { 

  // Creation and retrieval methods: 
  public static Logger getRootLogger(); 
  public static Logger getLogger(String name); 

  // printing methods: 
  public void debug(Object message); 
  public void info(Object message); 
  public void warn(Object message); 
  public void error(Object message); 
  public void fatal(Object message); 

  // generic printing method: 
  public void log(Level l, Object message); 

}

Loggers可以被指派优先级别。Level.html#DEBUG">DEBUG, INFO, WARN, ERROR 和FATAL这组 级别在org.apache.log4j.Level类中有定义。你也可以通过Level类的子类去定 义你自己的优先级别，尽管我们不鼓励你这样做。在后面我们会讲到一个更好 的方法。

如果一个logger没有被指定优先级别，它将继承最接近的祖先所被指定的优先级别。下面是更多关于优先级别的信息：

要保证所有的loggers最终都继承一个优先级别，root logger总是有一个被指派的优先级。

下面是具有各种指派优先级别值的四个表格，以及根据上面的规则所得出的继承优先级别。

在上面的示例1中，只有root logger被指派了级别。这个级别的值，Proot，被其它的loggers X, X.Y 和 X.Y.Z继承了。

在上面的示例2中，所有的loggers都有一个指派的级别值。不需要级别继承。

在示例3中，loggers root, X 和 X.Y.Z 分别被指派级别值Proot, Px 和Pxyz。Logger X.Y 从它的父辈X那里继承它的级别值。

在示例4中，loggers root和X 分别被指派级别值Proot和Px。Logger X.Y和X.Y.Z继承它们最接近的父辈X的被指派的级别值。

日志请求是通过调用一个日志实例的打印方法（之一）而产生的。这些打印方法是log4j/Logger.html#debug(java.lang.Object)">debug, info, warn, error, fatal 和 log。

根据定义，打印方法决定一个日志请求的级别。例如，如果c是一个日志实例，那么语句c.info("..") 就是级别为INFO的一个日志请求。  c.info("..")

只有一个日志请求(A logging request)的级别高于或等于它的logger级别的时候才能够被执行。否则，则被认为这个日志请求不能被执行。一个没有被定义优先级别的logger将从层次关系中的前辈那里继承优先级别。这个规则总结如下：

这个规则是log4j的核心。它假设级别是有先后顺序的。对于标准的优先级别来说，DEBUG < INFO < WARN < ERROR < FATAL。

这里是一个关于这个规则的例子：

   // get a logger instance named "com.foo"
   Logger  logger = Logger.getLogger("com.foo");

   // Now set its level. Normally you do not need to set the
   // level of a logger programmatically. This is usually done
   // in configuration files.
logger.setLevel(Level.INFO);

   Logger barlogger = Logger.getLogger("com.foo.Bar");

   // This request is enabled, because WARN >= INFO.
   logger.warn("Low fuel level.");

   // This request is disabled, because DEBUG < INFO.
   logger.debug("Starting search for nearest gas station.");

   // The logger instance barlogger, named "com.foo.Bar",
   // will inherit its level from the logger named
   // "com.foo" Thus, the following request is enabled
   // because INFO >= INFO.
   barlogger.info("Located nearest gas station.");

   // This request is disabled, because DEBUG < INFO.
   barlogger.debug("Exiting gas station search");

以一样的叁数名字调用getLogger方法，返回的reference总是指向完全相同的logger对象。

例如，在这里：

   Logger x = Logger.getLogger("wombat");
   Logger y = Logger.getLogger("wombat");

因此，通过这种方式可以配置一个logger，而不需要传递references就能在其 他地方得到相同的实例。在生物的父子关系中父母总是排放在孩子们前面， log4j loggers与此有相互矛盾的地方，那就是log4j loggers可以以任何顺序被 产生和配置。特别的是，一个"parent" logger 会找到并连接他的后代，即使他 是在他们之后被定义。

Log4j环境通常是在程序被初始化的时候被配置的。最好的方式是通过阅读一 个配置文件去配置。我们会马上讨论到这方面的内容。

Log4j使得通过软件组件的名称去定义loggers的名字很容易。这可以通过在每 个类中静态地instantiating一个logger，让logger的名字与这个合格的java类文 件名相同来完成。这是一种有用并且直观的定义loggers的方式。因为日志的 输出带有产生它们的logger的名字，这种命名策略使我们能够很方便地识别这 些log信息的来源。不过，尽管这是通用的一种loggers命名策略，Log4j没有限 制怎样对loggers进行命名。开发程序员可以根据自己的喜好随意定义 loggers。  software component

当然，至今所知的最好的命名策略还是以它们所在的类的名称来命名 loggers。

Appenders and Layouts

基于自身的logger选择性地使用或不使用日志请求（logging requests ）的能 力仅仅整个Log4j能力的一部分。Log4j允许将log信息输出到许多不同的输出 设备中。用log4j的语言来说，一个log信息输出目的地就叫做一个appender。 目前，log4j 的appenders可以将log信息输出到 console，files，GUI components，remote socket servers， JMS，NT Event Loggers，和 remote UNIX Syslog daemons。它还可以同时将log信息输出到多个输出设备 中。   NT Event Loggers

多个appenders可以和一个logger连接在一起。

使用addAppender方法把一个appender加入到给定的logger上。一个给定的 logger的每一个被允许的日志请求都会被传递给 这个logger的所有appenders，以及阶层中高级别的appenders。 换句话说appenders是从logger阶层中不断添加地被继承的。例如，一个 console appender加给了root logger，那么，这个root logger所有被允许输出 的日志信息将被输出到console。如果你又给一个名字为C的logger添加了一个 file appender，那么C 以及C的子辈的所有被允许的日志信息将被同时输出到 file appender和console appender。可以通过把additivity flag设置为false来覆 盖这个默认的行为从而使appender的继承关系不再是添加性的。  Each enabled logging request for a given logger will be forwarded to all the appenders in that logger as well as the appenders higher in the hierarchy.  setting the additivity flag

支配appender添加性的规则总结如下：

下面的表格显示一个示例：

通常，用户不仅希望自己指定log信息的输出目的地，而且，他们还希望指定 log信息的输出格式。这可以通过和appender相关的layout实现。Layout负责 根据用户的需要去格式化log信息的输出，而appender负责将一个格式化过的 log信息输出到它的目的地。 PatternLayout 是标准log4j发行包中的一部分，它 让用户根据和C语言中的printf方法相似的转换模式指定输出格式。

例如，具有"%r [%t] %-5p %c - %m%n" 转换格式的PatternLayout 将输出以下 的式样：

176 [main] INFO org.foo.Bar - Located nearest gas station.

第一个区域是从程序开始运行到输出日志信息所用的毫秒数。第二个区域是产 生日志请求的线程。第三个区域是这个log语句的优先级别。第四个区域是和 日志请求相关联的logger名字。在'-' 之后的文字是这个log信息的内容。

同样重要的是，log4j 将根据用户指定的标准来表达log信息的内容。例如，如 果你经常需要日志记录Oranges，Oranges是你当前项目中使用的一个对象类 型，那么你可以注册一个OrangeRenderer，这样每当需要日志记录一个 orange时，OrangeRenderer就会被调用。

对象的表达遵照类阶层（class hierarchy）形式。例如，假设oranges是 fruits，你注册了一个FruitRenderer，那么，包括oranges在内的所有的fruits 都将由FruitRenderer来表达，除非你自己为orange注册了一个特定的 OrangeRenderer。

Object renderers必须实施ObjectRenderer界面。

配 置

在程序代码中插入这些日志请求需要相当大的工作量。调查显示，大约%4左 右的代码是logging。因此，即便是中等大小的应用程序也需要在它们的代码中 至少包含有几千行的log语句。就从这个数目来看，管理这些log语句而不用人 工地去修改它们是十分重要的。

Log4j环境是完全能够通过编程来配置的。但是使用配置文件去配置则更灵 活。目前，Log4j的配置文件是以XML格式和JAVA properties (key=value) 格 式编写的。

假设我们有个叫MyApp的程序使用log4j，让我们来看看这是怎样做到的：

 import com.foo.Bar;

 // Import log4j classes.
import org.apache.log4j.Logger;
 import org.apache.log4j.BasicConfigurator;

 public class MyApp {

   // Define a static logger variable so that it references the
   // Logger instance named "MyApp".
static Logger logger = Logger.getLogger(MyApp.class);

   public static void main(String[] args) {

     // Set up a simple configuration that logs on the console.
BasicConfigurator.configure();

     logger.info("Entering application.");
     Bar bar = new Bar();
     bar.doIt();
     logger.info("Exiting application.");
   }
 }

MyApp 类首先引入log4j的相关类，然后定义一个命名为MyApp的静态logger变 量，而这个名字恰好和MyApp的类名一样。

MyApp类还使用了被定义在com.foo包中的Bar类：

												package com.foo;
            
 import org.apache.log4j.Logger;

 public class Bar {
static Logger logger = Logger.getLogger(Bar.class);

   public void doIt() {
     logger.debug("Did it again!");
   }
 }

通过调用BasicConfigurator.configure 方法产生一个相当简单的log4j的设置。 这个方法将一个 ConsoleAppender添加到root logger，从而让log信息输出到 console。通过把PatternLayout设置为 %-4r [%t] %-5p %c %x - %m%n来确 定输出格式。

注意，默认的root logger被指派为Level.DEBUG。

MyApp的输出是这样的：

0    [main] INFO  MyApp  - Entering application.
36   [main] DEBUG com.foo.Bar  - Did it again!
51   [main] INFO  MyApp  - Exiting application.

下面的图形描绘了在调用BasicConfigurator.configure方法之后，MyApp的对 象图表。

注意，log4j 的子代loggers只和它们现有的前辈链接。在这里，名字叫 com.foo.Bar的logger直接和root logger链接，因此绕过了没有被使用的com 或com.foo loggers。这样极大地提高了log4j的性能并减少了内存（memory） 的使用。

通过调用BasicConfigurator.configure方法来配置MyApp类。其它的类只需要 引入org.apache.log4j.Logger类，获取它们想要使用的loggers，就可以输出 log。

先前的例子总是输出同样的log信息。幸运的是，很容易修改MyApp程序就可 以在程序运行时对log输出进行控制。下面是略加修改后的版本：

 import com.foo.Bar;

 import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;

 public class MyApp {

   static Logger logger = Logger.getLogger(MyApp.class.getName());

   public static void main(String[] args) {


     // BasicConfigurator replaced with PropertyConfigurator.
PropertyConfigurator.configure(args[0]);

     logger.info("Entering application.");
     Bar bar = new Bar();
     bar.doIt();
     logger.info("Exiting application.");
   }
 }

这个例子中MyApp指示PropertyConfigurator方法去解读配置文件并设置相应 的logging 。

这里是一个配置文件的示例，这个配置文件产生和前面BasicConfigurator例子 完全一样的输出结果：

# Set root logger level to DEBUG and its only appender to A1.
log4j.rootLogger=DEBUG, A1

# A1 is set to be a ConsoleAppender.
log4j.appender.A1=org.apache.log4j.ConsoleAppender

# A1 uses PatternLayout.
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-4r [%t] %-5p %c %x - %m%n

假设我们不再需要com.foo软件包里任何组件的日志输出，下面的配置文件展 示了达到这一目的的一种可能的方法：

log4j.rootLogger=DEBUG, A1
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout

# Print the date in ISO 8601 format
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

# Print only messages of level WARN or above in the package com.foo.
log4j.logger.com.foo=WARN

由这个文件所配置的MyApp的日志输出如下：

				2000-09-07 14:07:41,508 [main] INFO  MyApp - Entering application.
2000-09-07 14:07:41,529 [main] INFO  MyApp - Exiting application.

因为logger com.foo.Bar 没有指定的优先级别，它就从com.foo中继承优先级 别，而com.foo的优先级别在配置文件中被设置为WARN。 Bar.doIt 方法里的 log语句的级别为DEBUG，比WARN级别低。所以，doIt()方法的日志请求就被 压制住了。

这里是另一个使用多个appenders的配置文件。

log4j.rootLogger=debug, stdout, R

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# Pattern to output the caller's file name and line number.
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=example.log

log4j.appender.R.MaxFileSize=100KB
# Keep one backup file
log4j.appender.R.MaxBackupIndex=1

log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n

调用以这个配置文件增强了的MyApp会把下列输出信息输出到控制台 （console）上。

 INFO [main] (MyApp2.java:12) - Entering application.
DEBUG [main] (Bar.java:8) - Doing it again!
 INFO [main] (MyApp2.java:15) - Exiting application.

另外，当root logger增加了第二个appender时，log信息将同时也被输出到 example.log文件中。当example.log文件达到100KB 后，example.log文件将 被rolled over。当roll-over 发生时，example.log 的老版本将自动被移到 example.log.1中去。

注意，要获得这些不同的logging行为并不需要重新编译代码。我们还可以简单 地通过修改log配置文件把log信息输出到UNIX Syslog daemon中，把所有 com.foo的日志输出转指向NT Event logger 中，或者把log事件输出到远程 log4j服务器中，当然它要根据局部服务器规则进行log，例如可以把log事件输 出到第二个log4j服务器中去。

默认的初始化过程

Log4j库没有对它的环境作任何假设。特别是，没有默认的log4j appenders。 不过在一些精细定义过的情况下，这个Logger类的静态的initializer会试图自动 配置log4j。 Java语言确保一个类的静态的initializer在这个类被装载到内存里 时被调用一次，而且仅仅一次。这点很重要，要记住不同的classloaders会装 载同一个类的不同复制版。这些同一个类的不同复制版在JVM看来是完全不相 关的。

默认的初始化在这样的环境中很有用处，那就是同一个程序依据运行时的环境 作不同用处。例如，同样一个程序可以在web-server的控制下作为单独的程 序，作为一个applet，或者作为一个servlet被使用。

默认的初始化运算法则定义如下：

1. 把log4j.defaultInitOverride的系统属性设置为 "false"以外的任何值将会造成 log4j跳过默认的初始化过程。
2. 把resource这个string变量设置为log4j.configuration系统属性的值。 最好的方法指定默认初始化文件是通过log4j.configuration系统属性来指定。 在log4j.configuration系统属性没有被定义的情况下，把resource这个string变 量设置成它的默认值"log4j.properties"。
3. 把resource变量转换为一个URL。
4. 如果这个resource变量不能转换为一个URL，例如，因为 MalformedURLException的缘故，那么就通过调用 org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)在 classpath上搜寻resource，它会返回一个URL。注意， string "log4j.properties"是一个不合式的URL。  org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)

   有关搜寻地址列单，请参看Loader.getResource(java.lang.String)。

5. 如果不能找到URL，那就放弃默认的初始化。否则，从URL配置log4j 。

   Configurator.html">PropertyConfigurator将被用于解读URL来配置log4j，除非这个URL以".xml"扩 展符结束，若这个URL以".xml"扩展符结束，DOMConfigurator则被使用。你可 以选择性地指定一个客户自己的configurator。log4j.configuratorClass系统属 性的值就是你客户自己的configurator的类名。你指定的客户configurator必须 实施Configurator接口。

配置示例

Tomcat下默认的初始化

默认的log4j初始化在web-server环境中特别有用。在Tomcat 3.x and 4.x下， 你应该把log4j.properties放置在你的网络程序的WEB-INF/classes目录下面。 Log4j自己会去找到属性文件并初始化。这样做又简单又有效。

你可以选择在Tomcat启动之前设置系统属性log4j.configuration 。对于 Tomcat 3.x ，TOMCAT_OPTS 环境变量被用来设置命令行选项。对于 Tomcat 4.0，使用CATALINA_OPTS环境变量而不是TOMCAT_OPTS 。

例子

Unix shell 命令

export TOMCAT_OPTS="-Dlog4j.configuration=foobar.txt"

例子

Unix shell 命令

   export TOMCAT_OPTS="-Dlog4j.debug -Dlog4j.configuration=foobar.xml"

例子

Windows shell 命令

   set TOMCAT_OPTS=-Dlog4j.configuration=foobar.lcf -Dlog4j.configuratorClass=com.foo.BarConfigurator

例子

Windows shell 命令

   set TOMCAT_OPTS=-Dlog4j.configuration=file:/c:/foobar.lcf

不同的网络应用程序通过它们各自的classloaders装载log4j的类。因此，每个 log4j环境的image会独自地，没有任何相互协调地行动。例如，在多个网络应 用程序的配置中，FileAppenders若定义得完全相同，它们就会编写相同的文 件。这样的结果就不那么令人满意。你必须保证不同的网络应用程序的log4j配 置不使用相同的系统资源。

初始化servlet

还可以使用一个特别的servlet来进行log4j初始化。这里就是个示例：

package com.foo;

import org.apache.log4j.PropertyConfigurator;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;

public class Log4jInit extends HttpServlet {

  public
  void init() {
    String prefix =  getServletContext().getRealPath("/");
    String file = getInitParameter("log4j-init-file");
    // if the log4j-init-file is not set, then no point in trying
    if(file != null) {
      PropertyConfigurator.configure(prefix+file);
    }
  }

  public
  void doGet(HttpServletRequest req, HttpServletResponse res) {
  }
}

在web.xml文件里为你的网络应用程序定义下面的servlet。

  <servlet>
    <servlet-name>log4j-init</servlet-name>
    <servlet-class>com.foo.Log4jInit</servlet-class>

    <init-param>
      <param-name>log4j-init-file</param-name>
      <param-value>WEB-INF/classes/log4j.lcf</param-value>
    </init-param>

<load-on-startup>1</load-on-startup>
  </servlet>

编写一个initialization servlet 是最灵活的方式来初始化log4j。不受任何限制， 你可以在这个servlet的init()方法里放入任何代码。

Nested Diagnostic Contexts

实际情况下的大多数系统都需要同时处理多个客户端问题。在这种系统的典型 的多线程实施中，通常是不同的线程去分别处理不同的客户需求。Logging特 别适合于复杂的程序跟踪和排错。一个通常的处理办法是通过给每个客户产生 一个新的分离开的logger来达到把不同的客户的日志输出信息区分开来。但这 促进了loggers的增殖，加大了logging的管理负担。

一个更简洁的技术是独特地标记来自于同一个客户的每一个日志请求。Neil Harrison 在他的书中"Patterns for Logging Diagnostic Messages," in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997) 对这个方法进行了描述。  Pattern Languages of Program Design 3

要独特地标记每个日志请求，用户把上下文信息送入NDC，NDC是 Nested Diagnostic Context的缩写。NDC类展示如下。

  public class NDC {
    // Used when printing the diagnostic
    public static String get();

    // Remove the top of the context from the NDC.
    public static String pop();

    // Add diagnostic context for the current thread.
    public static void push(String message);

    // Remove the diagnostic context for this thread.
    public static void remove();
  }

NDC类是作为一个保存线程上下文的stack来独个线程（per thread） 管理 的。注意，org.apache.log4j.NDC类中所有的方法都是静态的。假设NDC打印 功能被打开，每一次若有日志请求，相应的log4j组件就把这个当前线程的整个 NDC stack包括在日志输出中打印出来。这样做不需要用户干预，用户只需要 在代码中明确指定的几点通过push和pop方法将正确的信息放到NDC中就行 了。相反，per-client logger方法需要在代码中作很多更改。

为了说明这一点，我们举个有关一个servlet把信息内容发送到多个客户的例 子。这个Servlet程序在开始接到客户端的请求，执行其它代码之前，首先创建 一个NDC。该上下文信息可能是客户端的主机名，以及其他请求中固有的信 息，通常是包含在cookies中的信息。因此即便这个Servlet程序可能同时要服 务于多个客户，由相同的代码启动的这些logs，比如属于同一个logger，它们 仍然能够被区分开来，因为不同的客户端请求具有不同的NDC stack。这与在 客户请求期间把一个实例化的logger传递给所有要被执行的代码的复杂性形成 了反差。

然而，一些复杂的应用程序，比如虚拟网络服务器，必须依据虚拟主机的上下 文语言环境，以及发布请求的软体组件来作不同的log。最近的log4j发行版支 持多阶层树。这一功能的加强允许每个虚拟主机拥有它自己的logger阶层版 本。

性能

一个经常提出的争议就是logging的运算开销。这种关注是有道理的，因为即便 是一个中等大小的应用程序至少也会产生几千个log输出。许多工作都花费在 测量和改进logging性能上。Log4j声明它是快速和灵活的：速度第一，灵活性 第二。

用户需要清楚地了解下面这些与性能相关的问题：

1. Logging performance when logging is turned off.

   当logging被完全关闭或只是set of levels被关闭，日志请求的开销是方法的调 用和整数的比较。在一个233 MHz Pentium II机器上，这种开销通常在5 to 50 毫微秒范围内。  set of levels

   不过，方法的调用包含有参数的建造上的“隐闭”开销。

   例如下面的logger cat程序段中：

        logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
   

   不管message被日志记录与否，构造message参数的开销还是有的，比如说， 把整数i 和数组entry[i]转化为String，连接中间字串。参数构造的这种开销可能 很高，它依赖于所介入的参数数量有多少。

   为了避免这种参数构造开销，把以上的代码段改写为：

         if(logger.isDebugEnabled() {
           logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
         }
   

   如果排错功能不被使用，就不会有参数构造上的开销。但是，另一方面，如果 logger的排错功能被起用，就会有俩倍的开销用于评估logger是否被起用：一 次是判断debugEnabled，一次是判断debug是否被启用。但这不是极重的负 担，因为评估logger的时间只有整个log语句执行时间的1%

   在log4j中，把日志请求作为Logger类的实例。Logger是类而不是接口，这主 要是为了减少程序调用的开销，但牺牲了接口所能带来的灵活性。

   有些用户使用预处理或compile-time技术来编译所有log语句。这样logging方面 的性能是很好。但是，因为resulting application binary没有包含任何log语 句，你不能对这个二进制程序起用logging。在我看来，这是为了小的性能增加 而付出大的代价。

2. The performance of deciding whether to log or not to log when logging is turned on.

   本质上影响性能的因素是logger的层次关系。当logging功能被打开时，log4j仍 然需要把log请求的级别去与request logger的级别作比较。不过，有些loggers 并没有指派的优先级别，但它可以从它的上一层logger那里继承优先级别。因 此在继承优先级之前，logger可能需要搜索它的ancestors。

   Log4j在这方面做了很大的努力，以便使这种阶层的优先级别搜寻（hierarchy walk ）尽可能的快速。例如，子代loggers仅仅只和它们现有的ancestors链 接。在前面的BasicConfigurator示例中，叫做com.foo.Bar的logger 直接与 root logger链接，绕过了不存在的com或com.foo loggers。这极大地提高了优 先级别搜寻的速度。

   阶层的优先级搜寻（walking the hierarchy ）的开销在于它比logging完全关闭 时要慢三倍。

3. Actually outputting log messages

   这里讲的是log输出的格式化和把log信息发送到目标所在地的开销。Log4j在这 方面也下了大力气让格式化能尽快执行。对appenders也是一样。通常情况 下，格式化语句的开销可能是100到300微秒的处理时间。确切数字请参看 org.apache.log4.performance.Logging 。

尽管log4j具有许多功能特性，但速度是第一设计目标。为了提高性能，一些 log4j的部件曾经被重写过许多次。即使这样，log4j的贡献者们不断提出新的优 化办法。你应该很惊喜地发现当以SimpleLayout来配置时，性能测试显示使用 log4j日志和使用System.out.println日志同样快。

结论

Log4j是用Java编写的一个非常流行的logging开发包。它的一个显著特性之一 是在loggers里运用了继承的概念。使用这种logger的层次关系，就可能准确地 控制每一个log语句的输出。这样减少了log信息的输出量并降低了logging的开 销。

Log4j API的优点之一是它的可管理性。一旦log语句被插入到代码中，他们就 能被配置文件控制而无需重新编译源代码。Log信息的输出能够有选择地被起 用或关闭，用户能够按照自己选择的格式将这些log信息输出到许多不同的输 出设备中。Log4j软件包的设计是在代码中保留log语句的同时不造成很大的性 能损失。

感谢

JDK1.4的NIO有效解决了原有流式IO存在的线程开销的问题，在NIO中使用多线程，主要目的已不是为了应对每个客户端请求而分配独立的服务线程，而是通过多线程充分使用用多个CPU的处理能力和处理中的等待时间，达到提高服务能力的目的。

多线程的引入，容易为本来就略显复杂的NIO代码进一步降低可读性和可维护性。引入良好的设计模型，将不仅带来高性能、高可靠的代码，也将带来一个惬意的开发过程。

线程模型
NIO 的选择器采用了多路复用（Multiplexing）技术，可在一个选择器上处理多个套接字，通过获取读写通道来进行IO操作。由于网络带宽等原因，在通 道的读、写操作中是容易出现等待的，所以在读、写操作中引入多线程，对性能提高明显，而且可以提高客户端的感知服务质量。所以本文的模型将主要通过使用 读、写线程池来提高与客户端的数据交换能力。

如下图所示，服务端接受客户端请求后，控制线程将该请求的读通道交给读线程池，由读线程池分配 线程完成对客户端数据的读取操作；当读线程完成读操作后，将数据返回控制线程，进行服务端的业务处理；完成业务处理后，将需回应给客户端的数据和写通道提 交给写线程池，由写线程完成向客户端发送回应数据的操作。

（NIO 多线程服务器模型）
 

同时整个服务端的流程处理，建立于事件机制上。在 [接受连接－＞读－＞业务处理－＞写 －＞关闭连接 ]这个过程中，触发器将触发相应事件，由事件处理器对相应事件分别响应，完成服务器端的业务处理。
下面我们就来详细看一下这个模型的各个组成部分。

相关事件定义 在这个模型中，我们定义了一些基本的事件：
（1） onAccept：当服务端收到客户端连接请求时，触发该事件。通过该事件我们可以知道有新的客户端呼入。该事件可用来控制服务端的负载。例如，服务器可 设定同时只为一定数量客户端提供服务，当同时请求数超出数量时，可在响应该事件时直接抛出异常，以拒绝新的连接。

（2）onAccepted：当客户端请求被服务器接受后触发该事件。该事件表明一个新的客户端与服务器正式建立连接。

（3） onRead：当客户端发来数据，并已被服务器控制线程正确读取时，触发该事件。该事件通知各事件处理器可以对客户端发来的数据进行实际处理了。需要注意 的是，在本模型中，客户端的数据读取是由控制线程交由读线程完成的，事件处理器不需要在该事件中进行专门的读操作，而只需将控制线程传来的数据进行直接处 理即可。

（4）onWrite：当客户端可以开始接受服务端发送数据时触发该事件，通过该事件，我们可以向客户端发送回应数据。在本模型中，事件处理器只需要在该事件中设置

（5）onClosed：当客户端与服务器断开连接时触发该事件。

（6）onError：当客户端与服务器从连接开始到最后断开连接期间发生错误时触发该事件。通过该事件我们可以知道有什么错误发生。

事件回调机制的实现
在这个模型中，事件采用广播方式，也就是所有在册的事件处理器都能获得事件通知。这样可以将不同性质的业务处理，分别用不同的处理器实现，使每个处理器的业务功能尽可能单一。
如下图：整个事件模型由监听器、事件适配器、事件触发器、事件处理器组成。

（事件模型）
 

1. 监听器（Serverlistener）：这是一个事件接口，定义需监听的服务器事件，如果您需要定义更多的事件，可在这里进行扩展。
   

   public interface Serverlistener { public void onError(String error); public void onAccept() throws Exception; public void onAccepted(Request request) throws Exception; public void onRead(Request request) throws Exception; public void onWrite(Request request, Response response) throws Exception; public void onClosed(Request request) throws Exception; }

2. 事件适配器（EventAdapter）：对Serverlistener接口实现一个适配器(EventAdapter)，这样的好处是最终的事件处理器可以只处理所关心的事件。
   

   public abstract class EventAdapter implements Serverlistener { public EventAdapter() { } public void onError(String error) {} public void onAccept() throws Exception {} public void onAccepted(Request request) throws Exception {} public void onRead(Request request) throws Exception {} public void onWrite(Request request, Response response) throws Exception {} public void onClosed(Request request) throws Exception {} }

3. 事件触发器（Notifier）：用于在适当的时候通过触发服务器事件，通知在册的事件处理器对事件做出响应。触发器以Singleton模式实现，统一控制整个服务器端的事件，避免造成混乱。
   

   public class Notifier { private static Arraylist listeners = null; private static Notifier instance = null; private Notifier() { listeners = new Arraylist(); } /** * 获取事件触发器 * @return 返回事件触发器 */ public static synchronized Notifier getNotifier() { if (instance == null) { instance = new Notifier(); return instance; } else return instance; } /** * 添加事件监听器 * @param l 监听器 */ public void addlistener(Serverlistener l) { synchronized (listeners) { if (!listeners.contains(l)) listeners.add(l); } } public void fireOnAccept() throws Exception { for (int i = listeners.size() - 1; i >= 0; i--) ( (Serverlistener) listeners.get(i)).onAccept(); } ....// other fire method }

4. 事件处理器（Handler）：继承事件适配器，对感兴趣的事件进行响应处理，实现业务处理。以下是一个简单的事件处理器实现，它响应onRead事件，在终端打印出从客户端读取的数据。
   

   public class ServerHandler extends EventAdapter { public ServerHandler() { } public void onRead(Request request) throws Exception { System.out.println("Received: " + new String(data)); } }

5. 事件处理器的注册。为了能让事件处理器获得服务线程的事件通知，事件处理器需在触发器中注册。
   

   ServerHandler handler = new ServerHandler(); Notifier.addlistener(handler);

实现NIO多线程服务器
NIO多线程服务器主要由主控服务线程、读线程和写线程组成。

（线程模型）
 

1. 主控服务线程（Server）：主控线程将创建读、写线程池，实现监听、接受客户端请求，同时将读、写通道提交由相应的读线程（Reader）和写服务线程(Writer），由读写线程分别完成对客户端数据的读取和对客户端的回应操作。

   public class Server implements Runnable { .... private static int MAX_THREADS = 4; public Server(int port) throws Exception { .... // 创建无阻塞网络套接 selector = Selector.open(); sschannel = ServerSocketChannel.open(); sschannel.configureBlocking(false); address = new InetSocketAddress(port); ServerSocket ss = sschannel.socket(); ss.bind(address); sschannel.register(selector, SelectionKey.OP_ACCEPT); } public void run() { System.out.println("Server started ..."); System.out.println("Server listening on port: " + port); // 监听 while (true) { try { int num = 0; num = selector.select(); if (num > 0) { Set selectedKeys = selector.selectedKeys(); Iterator it = selectedKeys.iterator(); while (it.hasNext()) { SelectionKey key = (SelectionKey) it.next(); it.remove(); // 处理IO事件 if ( (key.readyOps() & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT) { // Accept the new connection ServerSocketChannel ssc = (ServerSocketChannel) key.channel(); notifier.fireOnAccept(); SocketChannel sc = ssc.accept(); sc.configureBlocking(false); // 触发接受连接事件 Request request = new Request(sc); notifier.fireOnAccepted(request); // 注册读操作,以进行下一步的读操作 sc.register(selector, SelectionKey.OP_READ, request); } else if ( (key.readyOps() & SelectionKey.OP_READ) == SelectionKey.OP_READ ) { Reader.processRequest(key); // 提交读服务线程读取客户端数据 key.cancel(); } else if ( (key.readyOps() & SelectionKey.OP_WRITE) == SelectionKey.OP_WRITE ) { Writer.processRequest(key); // 提交写服务线程向客户端发送回应数据 key.cancel(); } } } else { addRegister(); // 在Selector中注册新的写通道 } } catch (Exception e) { notifier.fireOnError("Error occured in Server: " + e.getMessage()); continue; } } } .... }

2. 读线程（Reader）：使用线程池技术，通过多个线程读取客户端数据，以充分利用网络数据传输的时间，提高读取效率。

   public class Reader extends Thread { public void run() { while (true) { try { SelectionKey key; synchronized (pool) { while (pool.isEmpty()) { pool.wait(); } key = (SelectionKey) pool.remove(0); } // 读取客户端数据，并触发onRead事件 read(key); } catch (Exception e) { continue; } } } .... }

3. 写线程（Writer）：和读操作一样，使用线程池，负责将服务器端的数据发送回客户端。

   public final class Writer extends Thread { public void run() { while (true) { try { SelectionKey key; synchronized (pool) { while (pool.isEmpty()) { pool.wait(); } key = (SelectionKey) pool.remove(0); } // 向客户端发送数据，然后关闭连接，并分别触发onWrite，onClosed事件 write(key); } catch (Exception e) { continue; } } } .... }

具体应用
NIO多线程模型的实现告一段落，现在我们可以暂且将NIO的各个API和烦琐的调用方法抛于脑后，专心于我们的实际应用中。
我们用一个简单的TimeServer（时间查询服务器）来看看该模型能带来多么简洁的开发方式。
在 这个TimeServer中，将提供两种语言（中文、英文）的时间查询服务。我们将读取客户端的查询命令（GB/EN），并回应相应语言格式的当前时间。 在应答客户的请求的同时，服务器将进行日志记录。做为示例，对日志记录，我们只是简单地将客户端的访问时间和IP地址输出到服务器的终端上。

1. 实现时间查询服务的事件处理器（TimeHandler）：
   

   public class TimeHandler extends EventAdapter { public TimeHandler() { } public void onWrite(Request request, Response response) throws Exception { String command = new String(request.getDataInput()); String time = null; Date date = new Date(); // 判断查询命令 if (command.equals("GB")) { // 中文格式 DateFormat cnDate = DateFormat.getDateTimeInstance(DateFormat.FulL, DateFormat.FulL, Locale.CHINA); time = cnDate.format(date); } else { // 英文格式 DateFormat enDate = DateFormat.getDateTimeInstance(DateFormat.FulL, DateFormat.FulL, Locale.US); time = enDate.format(date); } response.send(time.getBytes()); } }

   
   
2. 实现日志记录服务的事件处理器（LogHandler）：

   public class LogHandler extends EventAdapter { public LogHandler() { } public void onClosed(Request request) throws Exception { String log = new Date().toString() + " from " + request.getAddress().toString(); System.out.println(log); } public void onError(String error) { System.out.println("Error: " + error); } }

3. 启动程序：

   public class Start { public static void main(String[] args) { try { LogHandler loger = new LogHandler(); TimeHandler timer = new TimeHandler(); Notifier notifier = Notifier.getNotifier(); notifier.addlistener(loger); notifier.addlistener(timer); System.out.println("Server starting ..."); Server server = new Server(5100); Thread tServer = new Thread(server); tServer.start(); } catch (Exception e) { System.out.println("Server error: " + e.getMessage()); System.exit(-1); } } }

Cindy是一个Java异步I/O框架，提供了一个统一高效的模型，同时支持TCP、UDP以及Pipe，并能够方便的在异步和同步操作之间进行 切换。目前其实现是基于Java NIO，并计划通过JNI来支持各操作系统上本身提供的异步I/O功能，应用可以方便的通过运行期属性来方便的切换到更为高效的实现上。

为什么不使用Java IO？

Java IO包采用阻塞模型来处理网络操作。假设应用调用了read方法读取来自网络流上的数据，而数据尚未到达本机，则对read方法的调用将一直等到数据到达 并成功接收后才返回。由于IO包的所有操作会一直阻塞当前线程，为了不影响其他事务的处理，在一般情况下应用总是会用一个独立线程或线程池来处理这些 I/O操作。

Java IO包阻塞模型的优点就是非常简单易用，如果配合上线程池，效率也非常不错，所以得到了广泛的应用。但这种简单模型也有其固有的缺点：扩展性不足。如果应 用只需要进行少量的网络操作，那么开启若干个单独的I/O线程无伤大雅；但是如果是实现一个服务端的应用，需要同时处理成千上万个网络连接，采用阻塞模型 的话就要同时开启上千个线程。虽然现在强劲的服务器能够负担起这么多线程，但系统花在线程调度上的时间也会远远多于用于处理网络操作上的时间。

为什么要使用Java NIO？

采用IO包的阻塞模型，如果数据量不大的话，则线程的大部分时间都会浪费在等待上。对于稀缺的服务器资源而言，这是一种极大的浪费。

在Java 1.4中引入的NIO包里，最引人注目的就是提供了非阻塞I/O的实现。和IO包提供的阻塞模型不同的是，对一个非阻塞的连接进行操作，如果此时相应的状 态还未就绪，则调用会立即返回，而不是等待状态就绪后才返回。假设应用调用了read方法读取来自网络流上的数据，而此刻数据尚未到达本机，则对read 方法的调用将立即返回，并通知应用目前只能读到0个字节。应用可以根据自身的策略来进行处理，比如读取其他网络连接的数据等等，这就使得一个线程管理多个 连接成为可能。

NIO包还提供了Selector机制，将一个非阻塞连接注册在Selector上，应用就不需去轮询该连接当前是否可以读取或写入数据，在相应状 态就绪后Selector会通知该连接。由于一个Selector上可以注册多个非阻塞连接，这样就使得可以用更少的线程数来管理更多的连接。

为什么选择Cindy，而不直接使用NIO？

Java NIO包虽然提供了非阻塞I/O模型，但是直接使用NIO的非阻塞I/O需要成熟的网络编程经验，处理众多底层的网络异常，以及维护连接状态，判断连接超 时等等。对于关注于其业务逻辑的应用而言，这些复杂性都是不必要的。不同Java版本的NIO实现也会有一些Bug，Cindy会巧妙的绕开这些已知的 Bug并完成相应功能。并且NIO本身也在不断发展中，Java 1.4的NIO包中只实现了TCP/UDP单播/Pipe，Java 5.0中引入的SSLEngine类使得基于非阻塞的流协议（TCP/Pipe）支持SSL/TLS成为可能，在未来的版本中还可能会加入非阻塞多播的实 现。Cindy会关注这些新功能，并将其纳入到统一的框架中来。

Cindy虽然目前的实现是基于NIO，但它会不仅仅局限于NIO。等到一些基于操作系统本身实现的AIO（Asynchronous IO）类库成熟后，它也会加入对这些类库的支持，通过操作系统本身实现的AIO来提高效率。

如果应用程序只想使用一种高效的模型，而不想关心直接使用NIO所带来的这些限制，或希望将来无需更改代码就切换到更高效率的AIO实现上，那么 Cindy会是一个很好的选择。并且使用Cindy，应用可以在同步和异步之间进行无缝切换，对于大部分操作是异步，可某些特殊操作需要同步的应用而言， 这极大的提高了易用性。

Hello world example

场景：服务端监听本地的1234端口，打印任何收到的消息到控制台上；客户端建立TCP连接到本地的1234端口，发送完"Hello world!"，然后断开连接。

基于Java IO包的客户端示例

基于Java IO包的阻塞模型的示例，用于对比，不做额外说明。（异常处理代码略）

Socket socket = new Socket("localhost",1234);
OutputStream os = new BufferedOutputStream(socket.getOutputStream());
os.write("Hello world!".getBytes());
os.close();
socket.close();

基于Java IO包的服务端示例

基于Java IO包的阻塞模型的示例，用于对比，不做额外说明。（异常处理代码略）

ServerSocket ss = new ServerSocket(1234);
while (true) {
? final Socket socket = ss.accept();
? newThread() {

??? public void run() {
????? BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));
????? String line = null;
????? while ((line = br.readLine()) != null) {
??????? System.out.println(line);
????? }
    }

  }.start();
}

基于Cindy的同步客户端示例

								//create tcp session
Session session = SessionFactory.createSession(SessionType.TCP);    

//set remote address
session.setRemoteAddress(new InetSocketAddress("localhost", 1234)); 

//start session and wait until completed
session.start().complete();    

//create send packet
Packet packet = new DefaultPacket(BufferFactory.wrap("Hello world\!".getBytes())); 

//send packet and wait until completed
session.flush(packet).complete();

//close session and wait until completed
session.close().complete();

Step 1: create session

Session是连接的抽象，一个Session代表着一个连接。连接有多种类型，SessionType.TCP代表着TCP连接，SessionType.UDP代表着UDP连接，SessionType.PIPE代表着Pipe连接等等。

在这里通过SessionFactory.createSession(SessionType.TCP)创建了一个TCP连接。如果要创建UDP连接，可以使用类似的代码：

Session session = SessionFactory.createSession(SessionType.UDP);

连接创建后可以通过返回Session实例的getSessionType方法来得到该连接的类型。

Step 2: set the remote address

TCP需要先设置好要连接的地址才能开始连接，在这里是连接到本机的1234端口。对于UDP来说，这一步设置不是必须的。

Step 3: start session

参数设置完成后就可以通过session.start方法启动Session了。*和Java IO中的阻塞同步调用不同，由于Cindy是一个异步I/O框架，在调用session.start()方法并返回后，连接可能还没有建立成功。*如果我 们想要切换到同步阻塞的方式，比如等连接建立成功后才返回，则可以通过start方法返回的Future对象来进行切换。

Session中所有的异步方法(如start/close/flush/send等)的返回值均为Future对象，该对象代表着所进行的异步操作。我们可以通过三种方式来处理Future对象：

• 阻塞：调用Future.complete()，则该方法会一直等到异步操作完成后才返回；或者可以调用Future.complete(int timeout)来等待异步操作完成，如果在指定时间内操作未完成，则该方法也会返回。值得注意的是操作完成(isCompleted)包括操作成功和操作失败两种状态(isSucceeded)。
• 轮询：周期性的调用Future.isCompleted()方法来查询异步操作是否完成。
• 回调：通过Future.addListener()方法加入自定义的FutureListener，在异步操作结束后，Future会触发FutureListener的futureCompleted事件。对任何已完成的Future对象调用addListener方法会马上触发FutureListener的futureCompleted事件。

在该示例中我们采用的是第一种方式——阻塞，等待连接建立完成后才返回。可以通过Future.complete()方法的返回值或者 Session.isStarted()来判断连接是否建立成功。在这个简单的示例里假设不会出现任何连接错误，所以就不再判断异常情况了，不过在正式的 应用中应当注意相关的判断。

Step 4: the Packet/Buffer interface

任何数据要在网络上传输最终都得转换成字节流，Buffer接口就是字节流的抽象。注意的是这里使用的Buffer是net.sf.cindy.Buffer，而没有采用java.nio.Buffer，这个设计上的取舍可以参考以后的介绍。

而数据传输除了要有内容外，还得有目的地，这样才能把内容送到正确的地址上。Packet接口就代表着要发送的数据，包括一个Buffer对象和一 个目的地址------SocketAddress。对于流协议（如TCP/Pipe）而言，目的地址在建立连接的时候就已经设置好了，所以发送过程中无 需再进行设置，用默认的null即可；对于消息协议（比如非连接型的UDP），则需要在发送时指定每个包的目的地址。

在这里要将"Hello world!"转换为Buffer对象，可以通过BufferFactory来完成：BufferFactory.wrap("Hello world!".getBytes())，将一个字节数组包装成Buffer。

由于是TCP连接，目的地址在建立连接时就已经指定好了，所以可以简单的构造一个只有Buffer而没有SocketAddress的Packet对象：new DefaultPacket(buffer)。（DefaultPacket是Packet接口的默认实现）

Step 5: send packet

Session的flush方法和start方法一样都是异步方法，在调用flush并返回时，数据可能并没有发送完成，在该示例中仍然采用阻塞方式等待数据发送完成后才返回：session.flush(packet).complete()。

flush和send方法的区别在于：flush方法接受的参数是Packet对象，send方法接受的参数是Object对象，通过send方法发送的对象会被Session所关联的PacketEncoder转换为Packet对象再进行发送。

Step 6: close session

发送完成后需要关闭连接，close方法同样是一个异步方法，在这里等待连接完全关闭后才返回：session.close().complete()。

从这个同步的示例可以看到，虽然Cindy是一个异步I/O框架，但用它来完成同步的I/O操作也是一件非常容易的事情。

基于Cindy的异步客户端示例

								final Session session = SessionFactory.createSession(SessionType.TCP);
session.setRemoteAddress(new InetSocketAddress("localhost", 1234));
Future future = session.start();
future.addListener(new FutureListener() {

public void futureCompleted(Future future) throws Exception {
    Packet packet = new DefaultPacket("Hello world!".getBytes());
    session.flush(packet).complete();
    session.close();
  }

});

前面的三行代码和同步示例没有区别，只是在第四行代码中采用了回调的方式来处理Future对象，而不是通过阻塞的方式。当连接建立完成后，FutureListener的futureCompleted事件被触发，应用可以在该方法中做相应的事件处理。

在发送Packet的过程中，其实也可以采用回调的方式来处理。在这里仍采用同步方法处理，一方面是减少内嵌类的数量，另一方面是示例Cindy可以非常容易的切换同步和异步操作。后文对异步处理会有更详细的介绍。

基于Cindy的服务端示例

SessionAcceptor acceptor = SessionFactory.createSessionAcceptor(SessionType.TCP);
acceptor.setListenPort(1234);
acceptor.setAcceptorHandler(new SessionAcceptorHandlerAdapter() {

public void sessionAccepted(SessionAcceptor acceptor, Session session) throws Exception {
    session.setSessionHandler(new LogSessionHandler());
    session.start();
  }

});
acceptor.start();

Step 1: create SessionAcceptor

SessionAcceptor代表着连接的服务端，SessionAcceptor和Session是一对多关系，类似于IO包的ServerSocket和Socket。这里创建的是TCP服务端。

Step 2: set listen port

设置服务端的监听端口，在这里是1234端口；如果要设置监听地址，则可以通过setListenAddress来进行设置。

Step 3: set acceptor handler

每当SessionAcceptor上有连接建立成功，将会触发该SessionAcceptor所关联SessionAcceptorHandler的sessionAccepted事件，应用可以在该事件中为连接上的Session设置一些属性并开始或关闭连接。

SessionAcceptorHandler接口是处理SessionAcceptor产生的各种事件，SessionHandler接口则用于 处理Session产生的各种事件。在这里我们仅仅关心对象接收事件（objectReceived），当接收到对象后，将该对象打印到控制台上。（注： LogSessionHandler的代码没有列出来）

SessionHandler/SessionAcceptorHandler的更多介绍请参阅后面章节。

PacketEncoder/PacketDecoder

PacketEncoder

在前面的Hello world示例中，我们都是通过session.flush方法来发送数据，而该方法只接收Packet类型的参数，这就要求我们在发送任何数据前都要先 进行转换。比如在前面示例中，我们就得先将"Hello world!"字符串转换成一个代表"Hello world!"的Packet，然后再进行发送。

这种做法没有什么问题，其唯一的缺陷在于将发送逻辑和序列化逻辑耦合在一起。比如在上面的示例中，发送逻辑是将"Hello world!"发送出去，序列化逻辑是"Hello world"字符串的字节表示。虽然有一定的关联，但的确是两种不同的逻辑，比如我们可以更改序列化逻辑，通过Serializable接口来序列化 "Hello world"，但这并不影响发送逻辑。

神说，要有光，就有了光。你知道，神不关心光是怎么来的。PacketEncoder的作用就是分离发送逻辑和序列化逻辑。对于应用而言，在发送时 它只需要把要发送的对象传递给Session，至于怎么序列化，则由Session所关联的PacketEncoder来处理。所以在上面的Hello world示例中，发送逻辑可以改为：

session.send("Hello world!");

序列化逻辑可以通过PacketEncoder来设置：

session.setPacketEncoder(new PacketEncoder() {

public Packet encode(Session session, Object obj) throws Exception {
returnnew DefaultPacket(BufferFactory.wrap(obj.toString().getBytes()));
  }

});

如果要改变序列化逻辑，比如通过Serializable接口来序列化，则只需要更改PacketEncoder，而不需要改动发送代码：

session.setPacketEncoder(new SerialEncoder());

通过Cindy内置的PacketEncoderChain，应用可通过Session发送任意对象，把序列化逻辑完全交给PacketEncoder。如下面的伪码所示：

PacketEncoderChain chain = new PacketEncoderChain();
chain.addPacketEncoder(new Message1Encoder());
chain.addPacketEncoder(new Message2Encoder());

session.setPacketEncoder(chain);
session.send(new Message1());
session.send(new Message2());

PacketDecoder

PacketEncoder是用来处理序列化逻辑的，相应的，PacketDecoder则是用来处理反序列化逻辑的。

发送方通过session.send方法可以发送任意对象，Session关联的PacketEncoder会将该对象转换为Packet发送出 去；接收方收到了Packet后，也可以通过其关联的PacketDecoder将该Packet转换为一个对象，再通知应用。假设发送方用了 SerialEncoder来发送序列化对象，则接收方就可以使用SerialDecoder来进行反序列化，然后应用就可以直接对对象进行处理。

session.setPacketDecoder(new SerialDecoder());
session.setSessionHandler(new SessionHandlerAdapter() {

public void objectReceived(Session session, Object obj) throws Exception {
//obj即为反序列化后得到的对象
  }

}

Cindy源代码example目录下net.sf.cindy.example.helloworld包下提供了一个非常简单的示例。

应用在实现PacketDecoder的时候要注意判断当前已接收到的内容长度。

比如TCP是一个流协议，一方发送了1000个字节，另一方可能在接收的时候只收到了前200个字节，剩下的800个字节要在下次接收时才收到，可是需要1000个字节才能构造出一个完整的对象，则应用的PacketDecoder实现可能会类似于：

								public
Object decode(Session session, Packet packet) throws Exception {
  Buffer content = packet.getContent();  
if (content.remaining() >= 1000) {
//如果接收到的长度大于1000，则从Buffer中取出内容并返回decode结果
  }
returnnull;  //接收长度不足，等待全部接收完成后再decode，返回null不会触发objectReceived事件
}

SessionHandler/SessionHandlerAdapter

SessionHandler接口用于处理Session的各种事件。比如当连接建立成功后，会触发SessionHandler的 sessionStarted事件；连接关闭后，会触发SessionHandler的sessionClosed事件；对象发送成功后会触发 SessionHandler的objectSent事件；对象接收成功后会触发SessionHandler的objectReceived事件等等。

SessionHandlerAdapter是SessionHandler的空实现。即如果你仅仅对SessionHandler中某几个事件感 兴趣，就不用全部实现SessionHandler中定义的各种方法，而只需要继承自SessionHandlerAdapter，实现感兴趣的事件即 可。

通过SessionHandler，可以极大的减少内嵌类的数量。如前面的异步Hello world示例，如果用SessionHandler来改写，则会是：

Session session = SessionFactory.createSession(SessionType.TCP);
session.setRemoteAddress(new InetSocketAddress("localhost", 1234));
session.setSessionHandler(new SessionHandlerAdapter() {

public void sessionStarted(Session session) throws Exception {
// session started
    Buffer buffer = BufferFactory.wrap("Hello world!".getBytes());
    Packet packet = new DefaultPacket(buffer);
    session.send(packet);
  }

public void objectSent(Session session, Object obj) throws Exception {
// the packet have been sent, close current session
    session.close();
  };
};
session.start();

在上面的代码中，当sessionStarted事件触发后，即Session成功建立后，会发送"Hello world!"消息；当objectSent事件触发后，即消息发送成功，调用session.close()异步关闭连接。这些处理全部都是异步的，并 且仅仅使用了一个内嵌类。

SessionHandler中一共定义了如下几个方法：

• void sessionStarted(Session session) throws Exception //连接已建立
• void sessionClosed(Session session) throws Exception //连接已关闭
• void sessionTimeout(Session session) throws Exception //连接超时
• void objectReceived(Session session, Object obj) throws Exception //接收到了对象
• void objectSent(Session session, Object obj) throws Exception //发送了对象
• void exceptionCaught(Session session, Throwable cause) //捕捉到异常

如果通过session.setSessionTimeout方法设置了超时时间，则在指定的时间内没有接收或发送任何数据就会触发 sessionTimeout事件。发生了该事件并不代表着连接被关闭，应用可以选择关闭该空闲连接或者发送某些消息来检测网络连接是否畅通。默认情况下 sessionTimeout为0，即从不触发sessionTimeout事件。

如果通过PacketEncoder发送了任何对象，则objectSent事件将被触发（注：通过Session.flush方法发送的 Packet不会触发objectSent事件，只有通过Session.send方法发送的对象才会触发objectSent事件）；通过 PacketDecoder接收到任何对象，则objectReceived事件将被触发，一般情况下应用都通过监听该事件来对接收到的对象做相应处理。

exceptionCaught事件代表着session捕捉到了一个异常，这个异常可能是由于底层网络所导致，也可能是应用在处理SessionHandler事件时所抛出来的异常。请注意，如果应用在处理exceptionCaught事件中抛出运行期异常，则该异常不会再度触发exceptionCaught事件，否则可能出现死循环。 由于应用无法处理底层网络所引发的异常，所以在部署稳定后，可以通过指定运行期参数- Dnet.sf.cindy.disableInnerException来取消对底层网络异常的分发，或者判断异常类型——所有的内部异常都是从 SessionException基类继承下来的，应用可以根据这个特性来判断是底层网络出现了异常，还是SessionHandler或 SessionFilter中抛出了异常。

SessionFilter/SessionFilterAdapter

SessionFilter与SessionHandler有些类似，均用于处理Session的各种事件，不同的则是SessionFilter 先处理这些事件，并判断是否需要把该事件传递给下一个SessionFilter。等到所有SessionFilter处理完成后，事件才会传递给 SessionHandler由其来处理。

SessionFilterAdapter是SessionFilter的空实现，默认是把事件传递给下一个SessionFilter。SessionFilter中定义了如下几个方法：

• void sessionStarted(SessionFilterChain filterChain) throws Exception;
• void sessionClosed(SessionFilterChain filterChain) throws Exception;
• void sessionTimeout(SessionFilterChain filterChain) throws Exception;
• void objectReceived(SessionFilterChain filterChain, Object obj) throws Exception;
• void objectSent(SessionFilterChain filterChain, Object obj) throws Exception;
• void exceptionCaught(SessionFilterChain filterChain, Throwable cause);
• void packetReceived(SessionFilterChain filterChain, Packet packet) throws Exception;
• void packetSend(SessionFilterChain filterChain, Packet packet) throws Exception;
• void packetSent(SessionFilterChain filterChain, Packet packet) throws Exception;

其中前六种方法和SessionHandler的作用一致，后三种方法则是用于处理接收和发送的Packet的。

可以看到SessionFilter可以算做SessionHandler的超集，那为什么需要引入SessionHandler呢？

虽然SessionFilter和SessionHandler在表现形式上有很多接近的地方，但是在应用逻辑上却是处于不同的地位。 SessionHandler目的就是处理应用最为核心的业务逻辑，这些逻辑都是基于Object的，和网络层没有太大的关系；而 SessionFilter和网络层的关联就比较大了，一般用来处理网络相关的一些逻辑（如包压缩/解压缩、包加密/解密）或者是核心业务逻辑外的一些分 支逻辑（如记录日志、黑名单处理）。

基于SessionFilter，应用可以做很多扩展而不影响核心的业务处理（核心的业务处理应该放在SessionHandler中）。比如数据 包相关的扩展：加入SSLFilter，则所发送的数据都会被SSL编码后才发送，接收的数据会先被解码成明文才接收；加入ZipFilter，则可以压 缩所发送的数据，接收时再解压缩。比如统计的扩展：加入StatisticFilter，则可以统计发送和接收的字节数，以及发送速率。比如ACL的扩 展：加入AllowListFilter/BlockListFilter，则可以允许指定或限制某些IP地址访问；加入LoginFilter，如果用 户没有登录，则不把事件传递给后面处理业务逻辑的SessionFilter或SessionHandler。比如线程处理的扩展：加入 ThreadPoolFilter，可以指定让某个线程池来进行后面事件的处理。比如日志记录的扩展：加入LogFilter，则可以记录相应的事件信 息。

所列举的这些只是一些基于SessionFilter的常见应用，应用可以根据自身的业务需要来进行选择。Cindy所推荐的实践是将不同的业务逻辑分散到不同的SessionFilter中，在SessionHandler中只处理核心逻辑。

在这里可以示范一个ZipFilter的伪码：

								public class ZipFilter extends SessionFilterAdapter {

public void packetReceived(SessionFilterChain filterChain, Packet packet) throws Exception {
    Packet unzippedPacket = unzip(packet);  //解压缩
super.packetReceived(filterChain, unzippedPacket);//把解压缩后的包传递给下一个Filter
  }

public void packetSend(SessionFilterChain filterChain, Packet packet) throws  Exception {
    Packet zippedPacket = zip(packet);  //压缩
super.packetSend(filterChain, zippedPacket); //把压缩后的包传递给下一个Filter
  }
}

Buffer/Packet

在前面的示例中我们已经接触到了Buffer/Packet，Buffer是数据流的抽象，Packet是网络包的抽象。

Java NIO中已经提供了java.nio.ByteBuffer类用于表示字节流，为什么不直接使用java.nio.ByteBuffer？

java.nio.ByteBuffer虽然是NIO中表示字节流的标准类，但是对于高负荷的网络应用而言，其设计上存在着以下缺陷：

• ByteBuffer并不是一个接口，而是一个抽象类。最为关键的地方是其构造函数为包级私有，这意味着我们无法继承自ByteBuffer构造子类。
• ByteBuffer 仅仅是其所持有内容的一个外部包装，多个不同的ByteBuffer可以共享相同的内容。比如通过slice、duplicate等方法构造一个新的 ByteBuffer，该新ByteBuffer和原ByteBuffer共享的是同一份内容。这就意味着无法构造基于ByteBuffer的缓存机制。

比如如下代码：

ByteBuffer buffer1 = ByteBuffer.allocate(100);
ByteBuffer buffer2 = buffer1.slice();
System.out.println(buffer1 == buffer2);
System.out.println(buffer1.equals(buffer2));

打印出来的都是false，而实际上两个ByteBuffer共享的是同一份数据。在不经意的情况下，可能发生应用把两个ByteBuffer返回缓存中，被缓存当成是不同的对象进行处理，可能破坏数据完整性。

为什么Cindy使用自定义的Buffer接口？

• Buffer是一个接口，如果对现有的实现类不满意，应用可以方便的加入自己的实现
• 支持一系列的工具方法，比如indexOf/getString/putString/getUnsignedXXX等等，加入这些常用方法会给应用带来很大的方便
• 可以非常方便的与nio中的ByteBuffer做转换，并且效率上不会有太大损失。由于大部分的网络类库都是基于nio的ByteBuffer来设计的，这样保证了兼容性
• NIO的ByteBuffer无法表示ByteBuffer数组，而Cindy中提供了工具类把Buffer数组包装成一个Buffer
• Cindy的Buffer是可缓存的，对于高负荷的网络应用而言，这会带来性能上优势

在一般情况下，应用应该直接通过BufferFactory类来构造Buffer实例。目前BufferFactory类中有如下方法：

• Buffer wrap(byte[] array)
• Buffer wrap(byte[] array, int offset, int length)
• Buffer wrap(ByteBuffer buffer)
• Buffer wrap(Buffer[] buffers)
• Buffer allocate(int capacity)
• Buffer allocate(int capacity, boolean direct)

前四种方法都是包装方法，将现有的字节数组、ByteBuffer以及Buffer数组包装成一个单一的Buffer对象。第五和第六种方法是构造 一个新的Buffer对象，新构造Buffer对象的内容是不确定的（java.nio.ByteBuffer.allocate得到的内容是全0），可 能来自缓存或直接生成，依赖于对Buffer缓存的配置。一般情况下都是通过第五种方法构造新的Buffer对象，通过运行期参数- Dnet.sf.cindy.useDirectBuffer可以改变默认行为，是构造Non-Direct Buffer还是构造Direct Buffer。

默认情况下生成的Buffer是可以被缓存，在调用了session.send/flush方法后，Buffer的内容就会被释放掉，或者手动调用 Buffer.release也能释放Buffer所持有的内容。通过Buffer.isReleased方法可以可以判断当前的Buffer是否被释放 掉。对已经释放掉的Buffer进行get/put操作都会导致ReleasedBufferException，但是对 position/limit/capacity的操作还是有效的。如果应用不希望Buffer的内容被释放，可以通过设置permanent属性为 true来使得Buffer的内容不被释放。

是否所有Buffer都需要手动调用release来释放？

这里有一个基本的原则：谁生成，谁释放。比如应用调用BufferFactory.allocate(1024)得到了一个Buffer实例，这个Buffer实例是由应用生成出来的，那么应用在使用完该Buffer实例后就应该负责调用buffer.release将它释放掉。

不过框架为了提供应用的方便，所有通过session.send/flush方法发送的Buffer都会在发送完成后被释放。如果上面得到的这个 Buffer实例通过调用session.flush方法被发送出去，那么该Buffer实例就不需要再通过release方法手工释放了。

如果应用不手动release自己生成出来的Buffer，也不会造成内存泄漏，因为这些Buffer会通过Java的垃圾回收机制被回收掉。唯一的缺陷在于由于无法重用对象，性能可能会有少许的降低。

举个例子，假设你实现了一个特定的PacketDecoder：

								public class MyPacketDecoder implements PacketDecoder {

publicObject decode(Session session, Packet packet) throws Exception {
    Buffer content = packet.getContent();
    Buffer result = allocateBuffer();
    decodeContent(content, result);
return result;
  }

}

可以看到，在MyPacketDecoder的实现当中，并没有对接收到的Buffer调用release方法，因为这个Buffer并不是应用生 成出来的，不应该由应用来释放。在该MyPacketDecoder实现中生成了一个新的Buffer实例，并当作PacketDecoder的返回值。 这个新的实例是应用生成出来的，则应该由应用来释放，所以应用应该在相应的objectReceived事件中释放该Buffer实例，如：

								public void objectReceived(Session session, Object obj) throws Exception {
  Buffer buffer = (Buffer) obj;
try {
    process(buffer);
  } finally {
    buffer.release();
  }
}

Advanced Topic

JMX支持

通过运行期属性-Dnet.sf.cindy.useJmx可以开启JMX支持（Java 5.0中内置了JMX支持，如果运行在Java 1.4版本中，则需要手工下载相应类库）。

下图是通过jconsole进行JMX管理的示例：

流量控制

当网络接收的速度大于应用的处理速度时，如果不控制接收速率，则收到的消息会在队列中堆积，应用无法及时处理而造成内存溢出。Cindy 3.0中加入了流量控制功能，当接收队列中消息超过指定数量时，Cindy会放慢网络接收速度。该功能对于防止内存溢出以及应用程序调试有很大帮助。

可以通过运行期参数-Dnet.sf.cindy.dispatcher.capacity来指定队列中最多可以堆积的消息数。默认值是1000，即队列中消息数超过1000，网络接收速度就会放缓，等到消息数少于1000后，接收速度就会恢复正常。

Read packet size

Read packet size是指接收时每次读包所构造的缓冲区大小。对于TCP而言，这个值影响到的仅仅是效率；对于UDP则影响到数据正确性。

对于UDP应用，假设发送方发送的包所携带数据大小为1000字节，接收方的read packet size设置为600字节，则后面400个字节会被丢弃，这样
构造出来的逻辑包可能会不正确。

对于TCP应用，如果逻辑包是定长的，这个值最好也设为逻辑包的长度。该值太少，则可能导致在过多的包组合操作（比如逻辑包长度为1000字节， read packet size设置为100，则可能需要把10次接收到的packet组合成一个packet才能构造出一个逻辑包）；该值太大，可能造成内存的浪费（不过由于 Buffer缓存的存在会缓解这一情况）。

默认的read packet size是8192字节，可以通过运行期属性-Dnet.sf.cindy.session.readPacketSize来更改。如果对单独的 Session进行更改，则可以通过session的readPacketSize属性进行设置。

Direct ByteBuffer vs Non-Direct ByteBuffer

java.nio.ByteBuffer引入了这两种类型的ByteBuffer，在Cindy中也有基于这两种ByteBuffer的Buffer包装类。那么这两者的区别在什么地方？在什么环境下采用哪种类型的ByteBuffer会更有效率？

Non-direct ByteBuffer内存是分配在堆上的，直接由Java虚拟机负责垃圾收集，你可以把它想象成一个字节数组的包装类，如下伪码所示：

HeapByteBuffer extends ByteBuffer {
byte[] content;
int position, limit, capacity;
    ......
}

而Direct ByteBuffer是通过JNI在Java虚拟机外的内存中分配了一块，该内存块并不直接由Java虚拟机负责垃圾收集，但是在Direct ByteBuffer包装类被回收时，会通过Java Reference机制来释放该内存块。如下伪码所示：

DirectByteBuffer extends ByteBuffer {
long address;
int position, limit, capacity;

protected void finalize() throws Throwable{
//释放内存块，该段代码仅仅用于演示，真正的Direct ByteBuffer并不是通过finalize来释放的
        releaseAddress();  
       ......
    }
    ......
}

除开以上的这些外，如果我们查找Java实现类的代码，就可以了解到这两者之间更深入的区别。比如在Sun的Java实现中，绝大部分 Channel类都是通过sun.nio.ch.IOUtil这个工具类和外界进行通讯的，如FileChannel/SocketChannel等等。 简单的用伪码把write方法给表达出来（read方法也差不多，就不多做说明了）：

								int write(ByteBuffer src, ......) {
if (src instanceof DirectBuffer)
return writeFromNativeBuffer(...);
    ByteBuffer direct = getTemporaryDirectBuffer(src);
    writeFromNativeBuffer(direct,......);
    updatePosition(src);
    releaseTemporaryDirectBuffer(direct);
}

是的，在发送和接收前会把Non-direct ByteBuffer转换为Direct ByteBuffer，然后再进行相关的操作，最后更新原始ByteBuffer的position。这意味着什么？假设我们要从网络中读入一段数据，再 把这段数据发送出去的话，采用Non-direct ByteBuffer的流程是这样的：

								
网络 --> 临时的Direct ByteBuffer --> 应用 Non-direct ByteBuffer --> 临时的Direct ByteBuffer --> 网络

而采用Direct ByteBuffer的流程是这样的：

网络 --> 应用 Direct ByteBuffer --> 网络

可以看到，除开构造和析构临时Direct ByteBuffer的时间外，起码还能节约两次内存拷贝的时间。那么是否在任何情况下都采用Direct Buffer呢？

答案是否定的。对于大部分应用而言，两次内存拷贝的时间几乎可以忽略不计，而构造和析构Direct Buffer的时间却相对较长。在JVM的实现当中，某些方法会缓存一部分临时Direct ByteBuffer，意味着如果采用Direct ByteBuffer仅仅能节约掉两次内存拷贝的时间，而无法节约构造和析构的时间。就用Sun的实现来说，write(ByteBuffer)和 read(ByteBuffer)方法都会缓存临时Direct ByteBuffer，而write(ByteBuffer[])和read(ByteBuffer[])每次都生成新的临时Direct ByteBuffer。

根据这些区别，在选择ByteBuffer类型上有如下的建议：

• 如果你做中小规模的应用（在这里，应用大小是按照使用ByteBuffer的次数和规模来做划分的），并不在乎这些细节问题，请选择Non-direct ByteBuffer
• 如果采用Direct ByteBuffer后性能并没有出现你所期待的变化，请选择Non-direct ByteBuffer
• 如果没有Direct ByteBuffer Pool，尽量不要使用Direct ByteBuffer
• 除非你确定该ByteBuffer会长时间存在，并且和外界有频繁交互，可采用Direct ByteBuffer
• 如 果采用Non-direct ByteBuffer，那么采用非聚集(gather)的write/read(ByteBuffer)效果反而*可能*超出聚集的write/read (ByteBuffer[])，因为聚集的write/read的临时Direct ByteBuffer是非缓存的（在Sun的实现上是这样，其他的实现则不确定）

基本上，采用Non-direct ByteBuffer总是对的！因为内存拷贝需要的开销对大部分应用而言都可以忽略不计。在Cindy中，一般的应用只需要通过 BufferFactory.allocate方法来得到Buffer实例即可，默认设置下采用的是Non-Direct Buffer；通过BufferFactory.wrap方法包装字节数组或ByteBuffer得到的Buffer类也有很高的效率；只有通过 BufferFactory.wrap(Buffer[])方法目前还处于实验阶段，其效率不一定比生成一个大的Buffer，然后拷贝现有内容更快。如 果应用非常注重效率，要使用该方法上要多加注意。

默认参数设置

对Cindy中一些默认参数的配置可以通过以下两种方式：

• 配置文件配置

Cindy在启动时会在当前classpath上寻找cindy.properties文件，如果找到后会把该属性配置文件读入到缓存中。在该 properties中的配置无需net.sf.cindy.前缀，即如果要配置net.sf.cindy.enableJmx=true并且使用 DirectBuffer，则只需要在cindy.properties中加入：

enableJmx=true
useDirectBuffer=true

• 运行期属性配置

运行时通过-D参数指定的配置，如果和上面配置文件中的Key相同，则会覆盖配置文件的配置。通过-D参数指定配置时不能省略net.sf.cindy.前缀。

当前版本全部可以配置的属性请参见Cindy源代码包的readme.txt。

习惯了TCP编程，认为UDP可以包办这些问题是错误的。一个UDP应用程序要承担可靠性方面的全部工作，包括报文的丢失、重复、时延、乱序以及连接失效等问题。

通常我们在可靠性好，传输时延小的局域网上开发测试，一些问题不容易暴露，但在大型互联网上却会出现错误。

UDP协议把递送的可靠性责任推到了上层即应用层，下面简单编写了几个类来专门处理两个问题：乱序和丢包。

四个类：DataPacket 类，PacketHeader类，PacketBody类 ，DataEntry类，位于同一个文件DataPacket .java中。

DataPacket 类相当于一个门面模式，提供给外部使用，通信数据也在这个类中处理。

package com.skysoft.pcks;

import java.io.*;
import java.net.*;
import java.util.*;

public class  DataPacket {
  InputStream is;
  OutputStream os;
  PacketHeader header;
  PacketBody body;
  ArrayList al;
  public static final int DataSwapSize = 64532;

  /**
   * 在接收数据报使用
   */
  public DataPacket() {
    header = new PacketHeader();
    body = new PacketBody();
    al = new ArrayList();
  }
  /**
   * 在发送数据报时使用,它调用报文分割操作.
   * @param file String  硬盘文件
   */
  public DataPacket(String file) {
    this();
    try {
      is = new FileInputStream(file);
      header.CalcHeaderInfo(is.available());
      this.madeBody();
      is.close();
      //this.Gereratedata();
    }
    catch (FileNotFoundException ex) {
      ex.printStackTrace();
    }
    catch (IOException ex1) {
      ex1.printStackTrace();
    }
  }
  /**
   * 在发送数据报时使用,它调用报文分割操作.
   * @param url URL url地址
   */
  public DataPacket(URL url) {
    this();
    try {
      //is = url.openStream();
      URLConnection conn=url.openConnection();
      is=conn.getInputStream();
      int total=conn.getContentLength();
      header.CalcHeaderInfo(total);
      this.madeBody();
      //System.out.println(total+":"+total);
      is.close();
    }
    catch (IOException ex) {
      ex.printStackTrace();
    }
  }
  /**
   * 为发送构造分组,使用PackageHeader处理了报头格式,并为分组编序号.
   */
  private void madeBody() {
    al.clear();
    byte[] buffer;
    DataEntry de;
    for (int i = 0; i < header.fragmentcounter; i++) {
      try {
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        //is.skip(i * body.BODY_BUFFER_SIZE);
        header.ArrageSort(i);
        de = new DataEntry(PacketBody.BODY_BUFFER_SIZE);
        de.setSn(i);
        de.setStreamsize(header.getStreamsize());
        de.setFragmentcounter(header.getFragmentcounter());
        if (header.isWTailFragment(i)) {
          buffer = new byte[header.getMinfragment()];
          is.read(buffer, 0, buffer.length);
          header.setActByteSize(header.getMinfragment());
          de.setActByteSize(header.getMinfragment());
        }
        else {
          buffer = new byte[body.BODY_BUFFER_SIZE];
          is.read(buffer, 0, buffer.length);
        }
        //System.out.println("length-------"+i+" "+body.getBody().length+" "+header.getMinfragment());
        body.setBody(buffer);
        //System.out.println("length:" + i + " " + header.toString());
        bos.write(header.getByte(), 0, header.HEADER_BUFFER_SIZE);
        bos.write(body.getBody(), 0, body.getBody().length);
        de.setBytes(bos.toByteArray());
        al.add(de);
      }
      catch (IOException ex) {
        ex.printStackTrace();
      }
    }
  }
  /**
   * 为发送构造分组,没有考虑报头格式,也没有为分组编序号.
   */
  private void madeBody1() {
    al.clear();
    for (int i = 0; i < header.fragmentcounter; i++) {
      try {
        if (header.isWTailFragment(i))
          is.read(body.getBody(), i * body.BODY_BUFFER_SIZE,
                  header.getMinfragment());
        else
          is.read(body.getBody(), i * body.BODY_BUFFER_SIZE,
                  body.BODY_BUFFER_SIZE);
        ByteArrayOutputStream bos = new ByteArrayOutputStream();
        bos.write(header.getByte(), 0, header.HEADER_BUFFER_SIZE);
        bos.write(body.getBody(), header.HEADER_BUFFER_SIZE,
                  body.getBody().length);
        al.add(bos);
      }
      catch (IOException ex) {
        ex.printStackTrace();
      }
    }
  }
  /**
   * 在接收到报文后,对此报文执行组装,并处理报文丢失和乱序情况.
   * @param b1 byte[]
   */
  public void Add(byte[] b1) {
    byte[] buffer = (byte[]) b1.clone();
    handlerText(buffer);
    DataEntry de = new DataEntry(buffer, header.getActByteSize());
    de.setSn(header.getSn());
    de.setStreamsize(header.getStreamsize());
    de.setFragmentcounter(header.getFragmentcounter());
    al.add(de);
  }
  private void handlerText(byte[] buffer) {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    baos.write(buffer, 0, header.HEADER_BUFFER_SIZE);
    byte[] b=new byte[header.HEADER_BUFFER_SIZE];
    System.arraycopy(buffer,0,b,0,b.length);
    ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
    InputStreamReader isr = new InputStreamReader(bais);
    BufferedReader br = new BufferedReader(isr);
    try {
      header = new PacketHeader(br.readLine());
    }
    catch (Exception ex) {
      ex.printStackTrace();
    }
  }
 
  private String calFileSize(int size) {
    return size / 1024 + "K";
  }

  public ArrayList getDataPackets() {
    return al;
  }
/**
 * 是否接收完毕,通过序号是否等于最大段数来判断,这也许有问题,比如,正好是最后一个段丢失了,这样
 * 这个包整个就丢失了.
 * @return
 */
  public boolean isFull() {
    return this.header.getSn() == this.header.getFragmentcounter() - 1 ? true : false;
  }
/**
 * 判断是否只有一个段.
 * @return
 */
  public boolean isZero() {
    return this.header.getSn() == 0 ? true : false;
  }
/**
 * 该函数执行报文组装,不考虑丢失的报文.
 * @return
 */
  private ByteArrayOutputStream fetchDataPackets() {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    byte[] buffer = null;
    DataEntry de;
    for (int i = 0; i < al.size(); i++) {
      try {
        de = this.getSnData(i);
        buffer = de.getByte();
        if (header.getStreamsize() == de.getStreamsize()) {
          bos.write(de.getByte(), header.HEADER_BUFFER_SIZE, de.getActByteSize());
          System.out.println(de.toString() + " -- fetchDataPackets");
        }
      }
      catch (Exception ex) {
        ex.printStackTrace();
      }
    }
    return bos;
  }

  /**
   * 该函数执行报文组装,对于丢失的报文,写入空报文.
   * @return ByteArrayOutputStream
   */
  private ByteArrayOutputStream fetchDataPackets_sn() {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    byte[] buffer;
    DataEntry de;
    for (int i = 0; i < header.getFragmentcounter(); i++) {
      try {
        de = this.getSnData(i);
        if (de == null) {
          de = seachDeData(i);
        }
        buffer = de.getByte();
        //System.out.println(de.getSn() + ":" + i);
        //handlerText(buffer);
        //bos.write(buffer, header.HEADER_BUFFER_SIZE,
        //          buffer.length - header.HEADER_BUFFER_SIZE);
        if (header.getStreamsize() == de.getStreamsize()) {
          bos.write(de.getByte(), header.HEADER_BUFFER_SIZE,
                    de.getActByteSize());
          //System.out.println(de.toString());
        }
      }
      catch (Exception ex) {
        ex.printStackTrace();
      }
    }
    return bos;
  }

  /**
   * 对缓冲的数据包进行排序处理,即按顺序提取同一帧的数据,如果没有找到该序号的帧,则返回空值.
   * @param sn int 要找的帧序号.
   * @return DataEntry
   */
  private DataEntry getSnData(int sn) {
    DataEntry de = null;
    for (int i = 0; i < al.size(); i++) {
      de = (DataEntry) al.get(i);
      if (header.getStreamsize() == de.getStreamsize()) {
        if (sn == de.getSn())
          break;
        else
          de = null;
      }
    }
    return de;
  }

  /**
   * 按序号开始向前或者是向后寻找最近的帧片段,日后可以增加请求重发功能,通过开一个通信连接.
   * @param sn int
   * @return DataEntry
   */
  private DataEntry seachDeData(int sn) {
    DataEntry de = null;
    int init, min = 10000;
    DataEntry back, fore = null;
    for (int i = 0; i < al.size(); i++) {
      de = (DataEntry) al.get(i);
      if (header.getStreamsize() == de.getStreamsize()) {
        init = Math.abs(de.getSn() - sn);
        if (de.getFragmentcounter() != de.getSn() && init < min) {
          min = init;
          fore = de;
        }
      }
    }
    return fore;
  }

  /**
   * 除去最后一帧外,随机抽取一帧.
   * @return DataEntry
   */
  private DataEntry seachDeData() {
    DataEntry de = null;
    for (int i = 0; i < al.size(); i++) {
      de = (DataEntry) al.get(i);
      System.out.println("sky ::::" + de.getFragmentcounter() + ":" + de.getSn() +
                         ":" + i);
      if (header.getStreamsize() == de.getStreamsize()) {
        if (de.getFragmentcounter() != de.getSn()) {
          break;
        }
      }
    }
    return de;
  }
  /**
   * 生成组装完的结果数据.因为用图像来做测试,所以令其返回图像.
   * @return Image
   */
  public java.awt.Image Gereratedata() {
     ByteArrayInputStream bis;
     java.awt.image.BufferedImage bimage = null;
     try {
       byte[] b = fetchDataPackets_sn().toByteArray();
       //fetchDataPackets_old1()
       bis = new ByteArrayInputStream(b);
       bimage = javax.imageio.ImageIO.read(bis);

     }
     catch (Exception ex1) {
       ex1.printStackTrace();
     }
     return bimage;
  }

  public static void main(String args[]) {
    DataPacket dp = new DataPacket("e:\\nature\\14.jpg");
  }
}
/**
 * 数据实体,充当临时处理场所.
 * @author Administrator
 *
 */
class DataEntry {
  byte[] bytes;
  int fragmentcounter, sn, actbytesize;
  long streamsize;
  int minfragment;

  public DataEntry() {

  }

  public DataEntry(int size) {
    this.actbytesize = size;
  }

  public DataEntry(byte[] b, int i) {
    this.bytes = b;
    this.actbytesize = i;
  }

  public byte[] getByte() {
    return this.bytes;
  }

  public void setBytes(byte[] b) {
    this.bytes = b;
  }

  public void setStreamsize(long size) {
    this.streamsize = size;
  }

  public long getStreamsize() {
    return this.streamsize;
  }

  public int getMinfragment() {
    return minfragment;
  }

  public synchronized void setSn(int i) {
    this.sn = i;
  }

  public synchronized int getSn() {
    return sn;
  }

  public synchronized int getFragmentcounter() {
    return fragmentcounter;
  }

  public synchronized void setFragmentcounter(int c) {
    this.fragmentcounter = c;
  }

  public void setActByteSize(int size) {
    actbytesize = size;
  }

  public int getActByteSize() {
    return actbytesize;
  }

  public String toString() {
    return this.streamsize + "::" + this.fragmentcounter + "::" + this.sn +
        "::" + this.actbytesize + " recv DataEntry";
  }
}
/**
 * 报头,处理报头格式
 * @author Administrator
 *
 */
class PacketHeader implements Serializable{
  public static final int HEADER_BUFFER_SIZE = 1024;
  int fragmentcounter, sn;
  int actbytesize = PacketBody.BODY_BUFFER_SIZE;
  byte[] header; //= new byte[HEADER_BUFFER_SIZE];
  long streamsize;
  int minfragment;

  public PacketHeader() {

  }

  public PacketHeader(long l) {
    this.setStreamsize(l);

  }

  public PacketHeader(String s) {
    String[] tm = s.split("::");
    this.setActByteSize(Integer.parseInt(tm[3]));
    this.setSn(Integer.parseInt(tm[2]));
    this.setFragmentcounter(Integer.parseInt(tm[1]));
    this.setStreamsize(Long.parseLong(tm[0]));
  }

  /**
   * 根据文件的段的顺序生成数据头.
   * @param sn 文件序列
   */
  public void ArrageSort(int sn) {
    this.setSn(sn);
    this.setByte();
  }

  public void CalcHeaderInfo(long l) {
    this.setStreamsize(l);
    CalcHeaderInfo();
  }
  /**
   * 计算流要被分成的片段数量,并得出最小片段余量.
   */
  public void CalcHeaderInfo() {
    fragmentcounter = Math.round( (float) streamsize /
                                 PacketBody.BODY_BUFFER_SIZE);
    float critical = (float) streamsize / PacketBody.BODY_BUFFER_SIZE;
    if (critical - fragmentcounter < 0.5 && critical - fragmentcounter > 0)
      fragmentcounter++;
    minfragment = (int) (streamsize % PacketBody.BODY_BUFFER_SIZE);
  }

  public byte[] getHeader() {
    Long it = new Long(this.streamsize);
    return new byte[] {it.byte()};
  }

  public byte[] getByte() {
    return header; //this.toString().getBytes();
  }
  /**
   * 生成报头字节,首先取得数据包头 流尺寸::段片数::段顺序::段实际尺寸 的字节形式,
   * 然后加入回车换行符号,对于1024字节中剩余的部分一律写入元素为0的字节数组.
   */
  public void setByte() {
    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    byte[] buffer = this.toByte();
    try {
      bos.write(buffer);
      bos.write("\r\n".getBytes());
      bos.write(new byte[PacketHeader.HEADER_BUFFER_SIZE - buffer.length], 0,
                PacketHeader.HEADER_BUFFER_SIZE - buffer.length);
      header = bos.toByteArray();
    }
    catch (IOException ex) {
      ex.printStackTrace();
    }
  }

  public void setStreamsize(long size) {
    this.streamsize = size;
  }

  public long getStreamsize() {
    return this.streamsize;
  }

  public int getMinfragment() {
    return minfragment;
  }

  public synchronized void setSn(int i) {
    this.sn = i;
  }

  public int getSn() {
    return sn;
  }

  public int getFragmentcounter() {
    return fragmentcounter;
  }

  public synchronized void setFragmentcounter(int c) {
    this.fragmentcounter = c;
  }

  public void setActByteSize(int size) {
    actbytesize = size;
    setByte();
  }

  public int getActByteSize() {
    return actbytesize;
  }
  /**
   * 数据包头的格式为:流尺寸::段片数::段顺序::段实际尺寸
   * 报头字节长度是可变化的,比如,可以加入流的具体信息如:流所属文件的名称,文件类型以及一些其他信息.
   * @return String
   */
  public String toString() {
    return streamsize + "::" + this.fragmentcounter + "::" + this.getSn() +
        "::" + this.getActByteSize();
  }

  public byte[] toByte() {
    return this.toString().getBytes();
  }
  /**
   * 是否为尾段
   * @param i int
   * @return boolean
   */
  public boolean isWTailFragment(int i) {
    return (i == fragmentcounter - 1) ? true : false;
  }

}
/**
 * 用户数据区
 * @author Administrator
 *
 */
class PacketBody implements Serializable{
  public static final int BODY_BUFFER_SIZE = 63508; //65508
  byte[] body;

  public PacketBody() {
  }

  public void setBody(byte[] b) {
    this.body = b;
  }

  public byte[] getBody() {
    return body;
  }
}

这个数据处理类，将在接下来使用。

String utf8_;

utf8_ = request.getParameter("NAME");//从HTTP流中取"NAME"的UTF8数据

b = utf8_.getBytes("8859_1"); //中间用ISO-8859-1过渡

String name = new String(b, "GB2312"); //转换成GB2312字符

在 知道流长度的情况下将输入流转换成字节数组 Java中的输入流抽象类InputStream有int read(byte[] b, int off, int len)方法，参数中byte[] b是用来存放从InputStream中读取的数据,int off指定数组b的偏移地址，也就是数组b的起始下标，int len指定需要读取的长度，方法返回实际读取的字节数。刚学Java的朋友可能要说：先定义一个与流长度等长的字节数组，调用read方法，指定起始下标 为0，指定读取长度与数组长度等长，不是一下子可以读出来了吗？说的没错，笔者曾经也试着这样读取数据，但后来发现在读取网络数据时很不安全，我们想想在 网络上获取数据可能并没那么流畅，数据流的传送可能会断断续续，所以并不能保证一次就能读取全部数据，特别是在读取大容量数据时更是如此，所以我们必须在 读取数据时检测实际读到的长度，如果没有读完已知长度的数据就应该再次读取，以此循环检测，直到实际读取的长度累加与已知的长度相等，下面的代码实现了这 一功能：

ServletInputStream inStream = request.getInputStream(); //取HTTP请求流

int size = request.getContentLength(); //取HTTP请求流长度

byte[] buffer = new byte[size]; //用于缓存每次读取的数据

byte[] in_b = new byte[size]; //用于存放结果的数组

int count = 0;

int rbyte = 0;

while (count < size) { //循环读取

rbyte = inStream.read(buffer); //每次实际读取长度存于rbyte中

for(int i=0;i<rbyte;i++) {

in_b[count + i] = buffer[i];

}

count += rbyte;

}

在 不知道流长度的情况下将输入流转换成字节数组 前面介绍了已知流长度的情况下的转换方法，那么当我们不知道流有多长时，也就是说不能确定转换后的字节数组有多大时，该怎么处理呢？笔者查看了JDK文档 之后发现ByteArrayOutputStream有一个byte[] toByteArray()方法，该方法会自动创建一个字节数组，然后返回。于是就巧妙的用ByteArrayOutputStream来作中间过渡实现 转换，其它处理跟上面所介绍已知长度的情况差不多。假设需要被转换的流已经放在inStream里了，我们可以用如下的代码实现这一功能：

ByteArrayOutputStream swapStream = new ByteArrayOutputStream();

byte[] buff = new byte[100]; //buff用于存放循环读取的临时数据

int rc = 0;

while ((rc = inStream.read(buff, 0, 100)) > 0) {

swapStream.write(buff, 0, rc);

}

byte[] in_b = swapStream.toByteArray(); //in_b为转换之后的结果

许多程序员在使用 Java 语言编写 Internet 客户程序时并没有考虑这个问题，主要是因为在以前只有一种选择――阻塞通信。但是现在 Java 程序员有了新的选择，因此我们编写的每个客户程序也许都应该考虑一下。

非阻塞通信在 Java 2 SDK 的 1.4 版被引入 Java 语言。如果您曾经使用该版本编过程序，可能会对新的 I/O 库（NIO）留下了印象。在引入它之前，非阻塞通信只有在实现第三方库的时候才能使用，而第三方库常常会给应用程序引入缺陷。

NIO 库包含了文件、管道以及客户机和服务器套接字的非阻塞功能。库中缺少的一个特性是安全的非阻塞套接字连接。在 NIO 或者 JSSE 库中没有建立安全的非阻塞通道类，但这并不意味着不能使用安全的非阻塞通信。只不过稍微麻烦一点。

要完全领会本文，您需要熟悉：

• Java 套接字通信的概念。您也应该实际编写过应用程序。而且不只是打开连接、读取一行然后退出的简单应用程序，应该是实现 POP3 或 HTTP 之类协议的客户机或通信库这样的程序。
• SSL 基本概念和加密之类的概念。基本上就是知道如何设置一个安全连接（但不必担心 JSSE ――这就是关于它的一个“紧急教程”）。
• NIO 库。
• 在您选择的平台上安装 Java 2 SDK 1.4 或以后的版本。（我是在 Windows 98 上使用 1.4.1_01 版。）

如果需要关于这些技术的介绍，请参阅 参考资料部分。

那么到底什么是阻塞和非阻塞通信呢？

阻塞和非阻塞通信

阻塞通信意味着通信方法在尝试访问套接字或者读写数据时阻塞了对套接字的访问。在 JDK 1.4 之前，绕过阻塞限制的方法是无限制地使用线程，但这样常常会造成大量的线程开销，对系统的性能和可伸缩性产生影响。java.nio 包改变了这种状况，允许服务器有效地使用 I/O 流，在合理的时间内处理所服务的客户请求。

没 有非阻塞通信，这个过程就像我所喜欢说的“为所欲为”那样。基本上，这个过程就是发送和读取任何能够发送/读取的东西。如果没有可以读取的东西，它就中止 读操作，做其他的事情直到能够读取为止。当发送数据时，该过程将试图发送所有的数据，但返回实际发送出的内容。可能是全部数据、部分数据或者根本没有发送 数据。

阻塞与非阻塞相比确实有一些优点，特别是遇到错误控制问题的时候。在阻塞套接字通信中，如果出现错误，该访问会自动返回标志错误的代码。错误可能是由于网络超时、套接字关闭或者任何类型的 I/O 错误造成的。在非阻塞套接字通信中，该方法能够处理的唯一错误是网络超时。为了检测使用非阻塞通信的网络超时，需要编写稍微多一点的代码，以确定自从上一次收到数据以来已经多长时间了。

哪种方式更好取决于应用程序。如果使用的是同步通信，如果数据不必在读取任何数据之前处理的话，阻塞通信更好一些，而非阻塞通信则提供了处理任何已经读取的数据的机会。而异步通信，如 IRC 和聊天客户机则要求非阻塞通信以避免冻结套接字。

回页首

创建传统的非阻塞客户机套接字

Java NIO 库使用通道而非流。通道可同时用于阻塞和非阻塞通信，但创建时默认为非阻塞版本。但是所有的非阻塞通信都要通过一个名字中包含 Channel 的类完成。在套接字通信中使用的类是 SocketChannel， 而创建该类的对象的过程不同于典型的套接字所用的过程，如清单 1 所示。

												
            
SocketChannel sc = SocketChannel.open();
sc.connect("www.ibm.com",80);
sc.finishConnect();

            

必须声明一个 SocketChannel 类型的指针，但是不能使用 new 操作符创建对象。相反，必须调用 SocketChannel 类的一个静态方法打开通道。打开通道后，可以通过调用 connect() 方法与它连接。但是当该方法返回时，套接字不一定是连接的。为了确保套接字已经连接，必须接着调用 finishConnect() 。

当套接字连接之后，非阻塞通信就可以开始使用 SocketChannel 类的 read() 和 write() 方法了。也可以把该对象强制转换成单独的 ReadableByteChannel 和 WritableByteChannel 对象。无论哪种方式，都要对数据使用 Buffer 对象。因为 NIO 库的使用超出了本文的范围，我们不再对此进一步讨论。

当不再需要套接字时，可以使用 close() 方法将其关闭：

												
            
sc.close();

            

这样就会同时关闭套接字连接和底层的通信通道。

回页首

创建替代的非阻塞的客户机套接字

上述方法比传统的创建套接字连接的例程稍微麻烦一点。不过，传统的例程也能用于创建非阻塞套接字，不过需要增加几个步骤以支持非阻塞通信。

SocketChannel 对象中的底层通信包括两个 Channel 类： ReadableByteChannel 和 WritableByteChannel。 这两个类可以分别从现有的 InputStream 和 OutputStream 阻塞流中使用 Channels 类的 newChannel() 方法创建，如清单 2 所示：

												
            
ReadableByteChannel rbc = Channels.newChannel(s.getInputStream());
WriteableByteChannel wbc = Channels.newChannel(s.getOutputStream());

            

Channels 类也用于把通道转换成流或者 reader 和 writer。这似乎是把通信切换到阻塞模式，但并非如此。如果试图读取从通道派生的流，读方法将抛出 IllegalBlockingModeException 异常。

相反方向的转换也是如此。不能使用 Channels 类把流转换成通道而指望进行非阻塞通信。如果试图读从流派生的通道，读仍然是阻塞的。但是像编程中的许多事情一样，这一规则也有例外。

这种例外适合于实现 SelectableChannel 抽象类的类。 SelectableChannel 和它的派生类能够选择使用阻塞或者非阻塞模式。 SocketChannel 就是这样的一个派生类。

但是，为了能够在两者之间来回切换，接口必须作为 SelectableChannel 实现。对于套接字而言，为了实现这种能力必须使用 SocketChannel 而不是 Socket 。

回顾一下，要创建套接字，首先必须像通常使用 Socket 类那样创建一个套接字。套接字连接之后，使用 清单 2中的两行代码把流转换成通道。

												
            
Socket s = new Socket("www.ibm.com", 80);
ReadableByteChannel rbc = Channels.newChannel(s.getInputStream());
WriteableByteChannel wbc = Channels.newChannel(s.getOutputStream());

            

如前所述，这样并不能实现非阻塞套接字通信――所有的通信仍然在阻塞模式下。在这种情况下，非阻塞通信必须模拟实现。模拟层不需要多少代码。让我们来看一看。

从模拟层读数据

模拟层在尝试读操作之前首先检查数据的可用性。如果数据可读则开始读。如果没有数据可用，可能是因为套接字被关闭，则返回表示这种情况的代码。在清单 4 中要注意仍然使用了 ReadableByteChannel 读，尽管 InputStream 完全可以执行这个动作。为什么这样做呢？为了造成是 NIO 而不是模拟层执行通信的假象。此外，还可以使模拟层与其他通道更容易结合，比如向文件通道内写入数据。

												
            
/* The checkConnection method returns the character read when 
   determining if a connection is open.
 */

y = checkConnection();
if(y <= 0) return y;

buffer.putChar((char ) y);
return rbc.read(buffer); 

            

向模拟层写入数据

对于非阻塞通信，写操作只写入能够写的数据。发送缓冲区的大小和一次可以写入的数据多少有很大关系。缓冲区的大小可以通过调用 Socket 对象的 getSendBufferSize() 方法确定。在尝试非阻塞写操作时必须考虑到这个大小。如果尝试写入比缓冲块更大的数据，必须拆开放到多个非阻塞写操作中。太大的单个写操作可能被阻塞。

												
            
int x, y = s.getSendBufferSize(), z = 0;
int expectedWrite;
byte [] p = buffer.array();
ByteBuffer buf = ByteBuffer.allocateDirect(y);

/* If there isn't any data to write, return, otherwise flush the stream */

if(buffer.remaining() == 0) return 0;
os.flush()

for(x = 0; x < p.length; x += y)
{
    if(p.length - x < y)
    {
        buf.put(p, x, p.length - x);
        expectedWrite = p.length - x;
    }
    else
    {
        buf.put(p, x, y);
        expectedWrite = y;
    }

    /* Check the status of the socket to make sure it's still open */

    if(!s.isConnected()) break;

    /* Write the data to the stream, flushing immediately afterward */

    buf.flip(); 
    z = wbc.write(buf); os.flush();
    if(z < expectedWrite) break;
    buf.clear();

}
if(x > p.length) return p.length;
else if(x == 0) return -1;
else return x + z;

            

与读操作类似，首先要检查套接字是否仍然连接。但是如果把数据写入 WritableByteBuffer 对象，就像清单 5 那样，该对象将自动进行检查并在没有连接时抛出必要的异常。在这个动作之后开始写数据之前，流必须立即被清空，以保证发送缓冲区中有发送数据的空间。任何 写操作都要这样做。发送到块中的数据与发送缓冲区的大小相同。执行清除操作可以保证发送缓冲不会溢出而导致写操作被阻塞。

因为假定写操作只能写入能够写的内容，这个过程还必须检查套接字保证它在每个数据块写入后仍然是打开的。如果在写入数据时套接字被关闭，则必须中止写操作并返回套接字关闭之前能够发送的数据量。

BufferedOutputReader 可用于模拟非阻塞写操作。如果试图写入超过缓冲区两倍长度的数据，则直接写入缓冲区整倍数长度的数据（缓冲余下的数据）。比如说，如果缓冲区的长度是 256 字节而需要写入 529 字节的数据，则该对象将清除当前缓冲区、发送 512 字节然后保存剩下的 17 字节。

对于非阻塞写而言，这并非我们所期望的。我们希望分次把数据写入同样大小的缓冲区中，并最终把全部数据都写完。如果发送的大块数据留下一些数据被缓冲，那么在所有数据被发送的时候，写操作就会被阻塞。

模拟层类模板

整个模拟层可以放到一个类中，以便更容易和应用程序集成。如果要这样做，我建议从 ByteChannel 派生这个类。这个类可以强制转换成单独的 ReadableByteChannel 和 WritableByteChannel 类。

清单 6 给出了从 ByteChannel 派生的模拟层类模板的一个例子。本文后面将一直使用这个类表示通过阻塞连接执行的非阻塞操作。

												
            
public class nbChannel implements ByteChannel
{
    Socket s;
    InputStream is; OutputStream os;
    ReadableByteChannel rbc;
    WritableByteChannel wbc;

    public nbChannel(Socket socket);
    public int read(ByteBuffer dest);
    public int write(ByteBuffer src);
    public void close();

    protected int checkConnection();
}

            

使用模拟层创建套接字

使用新建的模拟层创建套接字非常简单。只要像通常那样创建 Socket 对象，然后创建 nbChannel 对象就可以了，如清单 7 所示：

												
            
Socket s = new Socket("www.ibm.com", 80);
nbChannel socketChannel = new nbChannel(s);
ReadableByteChannel rbc = (ReadableByteChannel)socketChannel;
WritableByteChannel wbc = (WritableByteChannel)socketChannel;

            

回页首

创建传统的非阻塞服务器套接字

服务器端的非阻塞套接字和客户端上的没有很大差别。稍微麻烦一点的只是建立接受输入连接的套接字。套接字必须通过从服务器套接字通道派生一个阻塞的服务器套接字绑定到阻塞模式。清单 8 列出了需要做的步骤。

												
            
ServerSocketChannel ssc = ServerSocketChannel.open();
ServerSocket ss = ssc.socket();
ss.bind(new InetSocketAddress(port));
SocketChannel sc = ssc.accept();

            

与客户机套接字通道相似，服务器套接字通道也必须打开而不是使用 new 操作符或者构造函数。在打开之后，必须派生服务器套接字对象以便把套接字通道绑定到一个端口。一旦套接字被绑定，服务器套接字对象就可以丢弃了。

通道使用 accept() 方法接收到来的连接并把它们转给套接字通道。一旦接收了到来的连接并转给套接字通道对象，通信就可以通过 read() 和 write() 方法开始进行了。

回页首

创建替代的非阻塞服务器套接字

实际上，并非真正的替代。因为服务器套接字通道必须使用服务器套接字对象绑定，为何不完全绕开服务器套接字通道而仅使用服务器套接字对象呢？不过这里的通信不使用 SocketChannel ，而要使用模拟层 nbChannel。

												
            
ServerSocket ss = new ServerSocket(port);
Socket s = ss.accept();
nbChannel socketChannel = new nbChannel(s);
ReadableByteChannel rbc = (ReadableByteChannel)socketChannel;
WritableByteChannel wbc = (WritableByteChannel)socketChannel;

            

回页首

创建 SSL 连接

创建SSL连接，我们要分别从客户端和服务器端考察。

从客户端

创建 SS L连接的传统方法涉及到使用套接字工厂和其他一些东西。我将不会详细讨论如何创建SSL连接，不过有一本很好的教程，“Secure your sockets with JSSE”（请参阅 参考资料），从中您可以了解到更多的信息。

创建 SSL 套接字的默认方法非常简单，只包括几个很短的步骤：

1. 创建套接字工厂。
2. 创建连接的套接字。
3. 开始握手。
4. 派生流。
5. 通信。

清单 10 说明了这些步骤：

												
            
SSLSocketFactory sslFactory = 
  (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket ssl = (SSLSocket)sslFactory.createSocket(host, port);
ssl.startHandshake();
InputStream is = ssl.getInputStream();
OutputStream os = ssl.getOutputStream();

            

默认方法不包括客户验证、用户证书和其他特定连接可能需要的东西。

从服务器端

建立SSL服务器连接的传统方法稍微麻烦一点，需要加上一些类型转换。因为这些超出了本文的范围，我将不再进一步介绍，而是说说支持SSL服务器连接的默认方法。

创建默认的 SSL 服务器套接字也包括几个很短的步骤：

1. 创建服务器套接字工厂。
2. 创建并绑定服务器套接字。
3. 接受传入的连接。
4. 开始握手。
5. 派生流。
6. 通信。

尽管看起来似乎与客户端的步骤相似，要注意这里去掉了很多安全选项，比如客户验证。

清单 11 说明这些步骤：

												
            
SSLServerSocketFactory sslssf = 
  (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
SSLServerSocket sslss = (SSLServerSocket)sslssf.createServerSocket(port);
SSLSocket ssls = (SSLSocket)sslss.accept();
ssls.startHandshake();
InputStream is = ssls.getInputStream();
OutputStream os = ssls.getOutputStream();

            

回页首

创建安全的非阻塞连接

要精心实现安全的非阻塞连接，也需要分别从客户端和服务器端来看。

从客户端

在客户端建立安全的非阻塞连接非常简单：

1. 创建并连接 Socket 对象。
2. 把 Socket 对象添加到模拟层上。
3. 通过模拟层通信。

清单 12 说明了这些步骤：

												
            
/* Create the factory, then the secure socket */

SSLSocketFactory sslFactory = 
  (SSLSocketFactory)SSLSocketFactory.getDefault();
SSLSocket ssl = (SSLSocket)sslFactory.createSocket(host, port);

/* Start the handshake.  Should be done before deriving channels */

ssl.startHandshake();

/* Put it into the emulation layer and create separate channels */

nbChannel socketChannel = new nbChannel(ssl);
ReadableByteChannel rbc = (ReadableByteChannel)socketChannel;
WritableByteChannel wbc = (WritableByteChannel)socketChannel;

            

利用前面给出的 模拟层类 就可以实现非阻塞的安全连接。因为安全套接字通道不能使用 SocketChannel 类打开，而 Java API 中又没有完成这项工作的类，所以创建了一个模拟类。模拟类可以实现非阻塞通信，无论使用安全套接字连接还是非安全套接字连接。

列出的步骤包括默认的安全设置。对于更高级的安全性，比如用户证书和客户验证， 参考资料 部分提供了说明如何实现的文章。

从服务器端

在服务器端建立套接字需要对默认安全稍加设置。但是一旦套接字被接收和路由，设置必须与客户端的设置完全相同，如清单 13 所示：

												
            
/* Create the factory, then the socket, and put it into listening mode */               

SSLServerSocketFactory sslssf = 
  (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();
SSLServerSocket sslss = (SSLServerSocket)sslssf.createServerSocket(port);
SSLSocket ssls = (SSLSocket)sslss.accept();

/* Start the handshake on the new socket */

ssls.startHandshake();

/* Put it into the emulation layer and create separate channels */

nbChannel socketChannel = new nbChannel(ssls);
ReadableByteChannel rbc = (ReadableByteChannel)socketChannel;
WritableByteChannel wbc = (WritableByteChannel)socketChannel;

            

同样，要记住这些步骤使用的是默认安全设置。

回页首

集成安全的和非安全的客户机连接

多数 Internet 客户机应用程序，无论使用 Java 语言还是其他语言编写，都需要提供安全和非安全连接。Java Secure Socket Extensions 库使得这项工作非常容易，我最近在编写一个 HTTP 客户库时就使用了这种方法。

SSLSocket 类派生自 Socket。 您可能已经猜到我要怎么做了。所需要的只是该对象的一个 Socket 指针。如果套接字连接不使用SSL，则可以像通常那样创建套接字。如果要使用 SSL，就稍微麻烦一点，但此后的代码就很简单了。清单 14 给出了一个例子：

												
            
Socket s;
ReadableByteChannel rbc;
WritableByteChannel wbc;
nbChannel socketChannel;

if(!useSSL) s = new Socket(host, port);
else
{
    SSLSocketFactory sslsf = SSLSocketFactory.getDefault();
    SSLSocket ssls = (SSLSocket)SSLSocketFactory.createSocket(host, port);
    ssls.startHandshake();
    s = ssls;
}

socketChannel = new nbChannel(s);
rbc = (ReadableByteChannel)socketChannel;
wbc = (WritableByteChannel)socketChannel;

...

s.close();

            

创建通道之后，如果套接字使用了SSL，那么就是安全通信，否则就是普通通信。如果使用了 SSL，关闭套接字将导致握手中止。

这种设置的一种可能是使用两个单独的类。一个类负责处理通过套接字沿着与非安全套接字的连接进行的所有通信。一个单独的类应该负责创建安全的连接，包括安全连接的所有必要设置，无论是否是默认的。安全类应该直接插入通信类，只有在使用安全连接时被调用。

回页首

最简单的集成方法

本文提出的方法是我所知道的把 JSSE 和 NIO 集成到同一代码中以提供非阻塞安全通信的最简单方法。尽管还有其他方法，但是都需要准备实现这一过程的程序员花费大量的时间和精力。

一种可能是使用 Java Cryptography Extensions 在 NIO 上实现自己的 SSL 层。另一种方法是修改现有的称为 EspreSSL （以前称为 jSSL）的定制 SSL 层， 把它改到 NIO 库中。我建议只有在您有很充裕的时间时才使用这两种方法。

参考资料 部分的可下载 zip 文件提供了示例代码，帮助您实践本文所述的技术，其中包括：

• nbChannel，清单 7 所介绍的模拟层的源代码。
• 连接到 Verisign's Web 站点并下载主页的示例 HTTPS 客户程序。
• 一个简单的非阻塞安全服务器 （Secure Daytime Server）。
• 集成的安全和非安全客户程序。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 下载本文的 源代码。
  
  
  
• " Introduction to Cryptography" 通过介绍 SSL 提供了加密的基本原理（PDF 格式）。
  
  
  
• " Secure Your Sockets with JSSE" 是应用 JSSE 的入门指南。
  
  
  
• " Merlin 给 Java 平台带来了非阻塞 I/O" ( developerWorks，2002 年 3 月)介绍了 Merlin 的 NIO 包的非阻塞特性，并提供了套接字编程的例子。
  
  
  
• " Merlin 的新 I/O 缓冲区的输入和输出" ( developerWorks，2003 年 3 月) 展示了如何为读/写基本数据类型这样的任务操作数据缓冲区和使用内存映射文件。
  
  
  
• " 为高级 JSSE 开发人员定制 SSL" ( developerWorks，2002 年 9 月) 示范了如何编程绕过 SSL 的一些限制。
  
  
  
• 教程 " Getting started with new I/O (NIO)" ( developerWorks，2003 年 7 月)非常详细地讨论了 NIO 库，从高级概念到隐藏的编程细节。
  
  
  
• IBMJSSE Overview概要介绍了 Java Secure Socket Extension。
  
  
  
• JSSE reference guide是该技术巨细无遗的参考资料。
  
  
  
• Ron Hitchens 所著的 Java NIO(O'Reilly & Associates, 2002)，深入探索了 1.4 版的新I/O功能。
  
  
  
• Java NIO还有一个支持网站， JavaNIO.info, 提供了代码开发的幻灯片、GUI 演示工具和该书的其他补充资料。
  
  
  
• 在 developerWorks Java 技术专区 上可以找到数百篇关于 Java 各个方面的文章。
  
  

回页首

关于作者

		Kenneth Ballard 目前在内布拉斯加州珀鲁州立大学学习计算机科学。他还是校内的学生报纸 Peru State Times 的职业作者。他从爱荷华州 Creston 的 Southwestern Community College 获得了计算机编程 Associate of Science 学位，在那里作为 PC 技术人员参加了一个工作效率研究项目。他的研究范围包括 Java 技术、C++、COBOL、Visual Basic 和网络。可以通过 kenneth.ballard@ptk.org 与 Kenneth 联系。

Java NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。

Java NIO出现不只是一个技术性能的提高，你会发现网络上到处在介绍它，因为它具有里程碑意义，从JDK1.4开始，Java开始提高性能相关的功能，从而使得Java在底层或者并行分布式计算等操作上已经可以和C或Perl等语言并驾齐驱。

如 果你至今还是在怀疑Java的性能，说明你的思想和观念已经完全落伍了，Java一两年就应该用新的名词来定义。从JDK1.5开始又要提供关于线程、并 发等新性能的支持，Java应用在游戏等适时领域方面的机会已经成熟，Java在稳定自己中间件地位后，开始蚕食传统C的领域。

本文主要简单介绍NIO的基本原理，在下一篇文章中，将结合Reactor模式和著名线程大师Doug Lea的一篇文章深入讨论。

NIO主要原理和适用。

NIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知的socketchannel告诉Selector,我们接着做别的事情，当有 事件发生时，他会通知我们，传回一组Selecti,我们读取这些Key,就会获得我们刚刚注册过的socketchannel,然后，我们从 这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。

Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生，比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。

了解了这个基本原理，我们结合代码看看使用，在使用上，也在分两个方向，一个是线程处理，一个是用非线程，后者比较简单，看下面代码：

这是一个守候在端口9000的noblock server例子，如果我们编制一个客户端程序，就可以对它进行互动操作，或者使用telnet 主机名　90000 可以链接上。

    本节示例源码：
package com.cyberobject.study;

import java.io.IOException;

import org.jdom.Attribute;
import org.jdom.Content;
import org.jdom.Document;
import org.jdom.Element;
import org.jdom.output.Format;
import org.jdom.output.XMLOutputter;

/**
 * @author kingwong
 *
 * TODO To change the template for this generated type comment go to
 * Window - Preferences - Java - Code Style - Code Templates
 */
public class TestJDOM {

 public static void main(String[] args)
 {
  Element rootElement = new Element("MyInfo");
  Document myDocument = new Document(rootElement);
  
//  Attribute rootAttri = new Attribute("comment","introduce myself");
//  rootElement.setAttribute(rootAttri);
  
  rootElement.setAttribute("comment","introduce myself");
  //rootElement.setAttribute(new Attribute("comment","introduce myself"));
//  Element sexElement = new Element("sex");
//  rootElement.addContent(sexElement);
  
//  Element nameElement = new Element("name");
//  nameElement.addContent("kingwong");
//  rootElement.addContent(nameElement);
  
  rootElement.addContent((Content)(new Element("name").addContent("kingwong")));
  rootElement.addContent(new Element("sex").setAttribute("","male"));
  rootElement.addContent((Content)(new Element("contract").addContent((Content)(new Element("telephone").addContent("87654321")))));
  
  rootElement.removeChild("sex");
  
  XMLOutputter xmlOut = new XMLOutputter(Format.getPrettyFormat());
  try {
   xmlOut.output(myDocument,System.out);
   //xmlOut.output(rootElement.getChild("name"),System.out);
   //String ōutString = xmlOut.outputString(myDocument);
  } catch (IOException e) {
   e.printStackTrace();
  }
 }
}

       
二、XML文档解析
    JDOM 不光可以很方便的建立XML文档，它的另一个用处是它能够读取并操作现有的 XML 数据。
    JDOM的解析器在org.jdom.input.*这个包里，其中的DOMBuilder的功能是将DOM模型的Document解析成JDOM模型的 Document；SAXBuilder的功能是从文件或流中解析出符合JDOM模型的XML树。由于我们经常要从一个文件里读取数据，因此我们应该采用 后者作为解析工具。
解析一个xml文档，基本可以看成以下几个步骤：
    1.实例化一个合适的解析器对象
        本例中我们使用SAXBuilder:
        SAXBuilder sb = new SAXBuilder();
    2.以包含XML数据的文件为参数，构建一个文档对象myDocument
        Document myDocument = sb.build(/some/directory/myFile.xml);
    3.获到根元素
        Element rootElement = mygetRootElement();
       
        一旦你获取了根元素，你就可以很方便地对它下面的子元素进行操作了，下面对Element对象的一些常用方法作一下简单说明：
        getChild("childname") 返回指定名字的子节点,如果同一级有多个同名子节点，则只返回第一个；如果没有返回null值。
        getChildren("childname") 返回指定名字的子节点List集合。这样你就可以遍历所有的同一级同名子节点。
        getAttribute("name") 返回指定属性名字的值。如果没有该属性则返回null,有该属性但是值为空，则返回空字符串。
        getChildText("childname") 返回指定子节点的内容文本值。
        getText() 返回该元素的内容文本值。
       
        还有其他没有罗列出来的方法，如果需要的话，可以随时查阅JDOM的在线文档：http://www.jdom.org/docs/apidocs/index.html。当然你可以在你需要的地方添加、删除元素操作，还记得上面的创建XML的方法吗？呵呵~~~
       
        学习新东东还是从实例学起最为快捷，下面简单举个例子，就以上面的XML样本代码来学习JDOM的XML解析。本例中读取了样本XML文件里一些属性和content，最后我们还在contact元素里插入了一个新元素<email ="wanghua@cyberobject.com" />。尽管我们实现了对于XML的基本操作，细心的朋友可能会
有 疑问：如果XML文档的层次稍微复杂一些，如果嵌套多达几十上百层的话（开个玩笑），如果靠这样从根元素一级一级地通过getChild ("childname")来访问子元素的话，将会非常痛苦！是的，的确是这样，但是我们有另一个有力的工具XPath，为什么不用呢？这是后话！先卖个 关子（手敲累啦，下回吧，呵呵）。
       
/*
 * Created on 2004-8-21
 *
 * TODO To change the template for this generated file go to
 * Window - Preferences - Java - Code Style - Code Templates
 */
package com.cyberobject.study;

import org.jdom.Document;
import org.jdom.Element;
import org.jdom.input.SAXBuilder;
import org.jdom.output.Format;
import org.jdom.output.XMLOutputter;

本文可看成是对Doug Lea Scalable IO in Java一文的翻译。

当前分布式计算　Web Services盛行天下，这些网络服务的底层都离不开对socket的操作。他们都有一个共同的结构：
1. Read request
2. Decode request
3. Process service
4. Encode reply
5. Send reply

经典的网络服务的设计如下图，在每个线程中完成对数据的处理：

但这种模式在用户负载增加时，性能将下降非常的快。我们需要重新寻找一个新的方案，保持数据处理的流畅，很显然，事件触发机制是最好的解决办法，当有事件发生时，会触动handler,然后开始数据的处理。

Reactor模式类似于AWT中的Event处理：

Reactor模式参与者

1.Reactor 负责响应IO事件，一旦发生，广播发送给相应的Handler去处理,这类似于AWT的thread
2.Handler 是负责非堵塞行为，类似于AWT ActionListeners；同时负责将handlers与event事件绑定，类似于AWT addActionListener

如图：

Java的NIO为reactor模式提供了实现的基础机制，它的Selector当发现某个channel有数据时，会通过SlectorKey来告知我们，在此我们实现事件和handler的绑定。

我们来看看Reactor模式代码:

以上代码中巧妙使用了SocketChannel的attach功能，将Hanlder和可能会发生事件的channel链接在一起，当发生事件时，可以立即触发相应链接的Handler。

再看看Handler代码:

注意在Handler里面又执行了一次attach，这样，覆盖前面的Acceptor，下次该Handler又有READ事件发生时，将直接触发Handler.从而开始了数据的读　处理　写　发出等流程处理。

将数据读出后，可以将这些数据处理线程做成一个线程池，这样，数据读出后，立即扔到线程池中，这样加速处理速度：

更进一步，我们可以使用多个Selector分别处理连接和读事件。

一个高性能的Java网络服务机制就要形成，激动人心的集群并行计算即将实现。

本文是一篇简短入门文章 . 本文假设读者对 Java 的 IO 系统和 Java 的网络系统有所了解 .

正文 :

关于文件传输的问题 , 实际也是一种 IO 读写的基本问题 . 对于网络而言也是一种 IO 读写问题 . 因此所谓网络的文件传输实际是两种 IO 问题的综合讨论 . 这里我们首先分析一个图示 . 然后围绕这个图示来讨论 :

图 1 :

分析图 1 我们基本可以知道从服务器文件系统中通过流把文件中的数据写入到服务器的进程中 , 然后把进程中的数据通过网络 IO 系统传递到客户机 , 这个阶段 , 网络中的数据以字节流的形式保存 . 当该字节流被客户进程接受后 , 客户进程通过客户本地文件流写入客户本地的文件系统中 .

根据以上分析 , 我们基本可以确定我所需要处理的问题了 . 首先我们需要可以对本地文件系统 IO 操作的操作接口 , 然后是一个可以对网络 IO 系统进行操作的操作接口 , 已经一个可以把数据包装成字节流的操作接口 , 他们分别可以提供客户和服务器两个进程进行读写的操作 . 如下图所示 :

图 2:

根据以上分析 , 我们可以把问题归结到对以下编程接口的需求上 :

1.         字节包装器和字节解包器 ,

2.         网络传输器和网络接收器

3.         本地文件读 / 写器

而这些 Java 本身的 API 就已经提供 . 他们都被包装到 java.io 和 java.net 这两个包里 , 这里我提供一个基于 TCP/IP 的实现版本 , 使用基于连接的方式来完成工作 . 我们首先介绍几个相关的 JDK 中的类来完成以上任务 ,

1.       DataOutputStream 和 DataInputStream 实现类提供了上面的字节包装和解包器的实现

2.       ServerSocket 和 Socekt 提供了基于连接的网络传输和接受接口

3.       File,FileInputStream 和 FileOutputStream 提供了基本的本地文件输入输出接口 .

服务器端实现代码 :

import java.io.*;

import java.net.*;

public class FileServer{

       public static void main(String[] args)throws Exception{

              // 创建文件流用来读取文件中的数据

              File file=new File("lishengjie.jpg");

              FileInputStream fos=new FileInputStream(file);

              // 创建网络服务器接受客户请求

              ServerSocket ss=new ServerSocket(3108);

              Socket client=ss.accept();

              // 创建网络输出流并提供数据包装器

              OutputStream netOut=client.getOutputStream();

              OutputStream doc=new DataOutputStream(new BufferedOutputStream(netOut));

              // 创建文件读取缓冲区

              byte[] buf=new byte[2048];

              int num=fos.read(buf);

              while(num!=(-1)){// 是否读完文件

                     doc.write(buf,0,num);// 把文件数据写出网络缓冲区

                     doc.flush();// 刷新缓冲区把数据写往客户端

                     num=fos.read(buf);// 继续从文件中读取数据

              }

              fos.close();

              doc.close();