序言


本指南对Netty 进行了介绍并指出其意义所在。


1. 问题


现在，我们使用适合一般用途的应用或组件来和彼此通信。例如，我们常常使用一个HTTP客户端从远程服务器获取信息或者通过web services进行远程方法的调用。

然而，一个适合普通目的的协议或其实现并不具备其规模上的扩展性。例如，我们无法使用一个普通的HTTP服务器进行大型文件，电邮信息的交互，或者处理金 融信息和多人游戏数据那种要求准实时消息传递的应用场景。因此，这些都要求使用一个适用于特殊目的并经过高度优化的协议实现。例如，你可能想要实现一个对 基于AJAX的聊天应用，媒体流或大文件传输进行过特殊优化的HTTP服务器。你甚至可能想去设计和实现一个全新的，特定于你的需求的通信协议。

另一种无法避免的场景是你可能不得不使用一种专有的协议和原有系统交互。在这种情况下，你需要考虑的是如何能够快速的开发出这个协议的实现并且同时还没有牺牲最终应用的性能和稳定性。


2. 方案


Netty 是一个异步的，事件驱动的网络编程框架和工具，使用Netty 可以快速开发出可维护的，高性能、高扩展能力的协议服务及其客户端应用。

也就是说，Netty 是一个基于NIO的客户，服务器端编程框架，使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。

“快速”和“简单”并不意味着会让你的最终应用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMPT,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。

一些用户可能找到了某些同样声称具有这些特性的编程框架，因此你们可能想问Netty 又有什么不一样的地方。这个问题的答案是Netty 项目的设计哲学。从创立之初，无论是在API还是在其实现上Netty 都致力于为你提供最为舒适的使用体验。虽然这并不是显而易见的，但你终将会认识到这种设计哲学将令你在阅读本指南和使用Netty 时变得更加得轻松和容易。

第一章. 开始


这一章节将围绕Netty的核心结构展开，同时通过一些简单的例子可以让你更快的了解Netty的使用。当你读完本章，你将有能力使用Netty完成客户端和服务端的开发。

如果你更喜欢自上而下式的学习方式，你可以首先完成 第二章：架构总览 的学习，然后再回到这里。

1.1. 开始之前


运行本章示例程序的两个最低要求是：最新版本的Netty程序以及JDK 1.5或更高版本。最新版本的Netty程序可在项目下载页 下载。下载正确版本的JDK，请到你偏好的JDK站点下载。

这就已经足够了吗？实际上你会发现，这两个条件已经足够你完成任何协议的开发了。如果不是这样，请联系Netty项目社区 ，让我们知道还缺少了什么。

最终但不是至少，当你想了解本章所介绍的类的更多信息时请参考API手册。为方便你的使用，这篇文档中所有的类名均连接至在线API手册。此外，如果本篇文档中有任何错误信息，无论是语法错误，还是打印排版错误或者你有更好的建议，请不要顾虑，立即联系Netty项目社区 。

1.2. 抛弃协议服务


在这个世界上最简化的协议不是“Hello,world!”而是抛弃协议 。这是一种丢弃接收到的任何数据并不做任何回应的协议。

实现抛弃协议（DISCARD protocol），你仅需要忽略接受到的任何数据即可。让我们直接从处理器（handler）实现开始，这个处理器处理Netty的所有I/O事件。

Java代码
package org.jboss.netty.example.discard;

@ChannelPipelineCoverage("all")1
public class DiscardServerHandler extends SimpleChannelHandler {2

@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {3
}

@Override
public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) {4
e.getCause().printStackTrace();

Channel ch = e.getChannel();
ch.close();
}
}


代码说明

1)ChannelPipelineCoverage注解了一种处理器类型，这个注解标示了一个处理器是 否可被多个Channel通道共享（同时关联着ChannelPipeline）。DiscardServerHandler没有处理任何有状态的信息， 因此这里的注解是“all”。

2)DiscardServerHandler继承了SimpleChannelHandler，这也是一个ChannelHandler 的实现。SimpleChannelHandler提供了多种你可以重写的事件处理方法。目前直接继承SimpleChannelHandler已经足够 了，并不需要你完成一个自己的处理器接口。

3)我们这里重写了messageReceived事件处理方法。这个方法由一个接收了客户端传送数据的MessageEvent事件调用。在这个例子中，我们忽略接收到的任何数据，并以此来实现一个抛弃协议（DISCARD protocol）。

4)exceptionCaught 事件处理方法由一个ExceptionEvent异常事件调用，这个异常事件起因于Netty的I/O异常或一个处理器实现的内部异常。多数情况下，捕捉 到的异常应当被记录下来，并在这个方法中关闭这个channel通道。当然处理这种异常情况的方法实现可能因你的实际需求而有所不同，例如，在关闭这个连 接之前你可能会发送一个包含了错误码的响应消息。

目前进展不错，我们已经完成了抛弃协议服务器的一半开发工作。下面要做的是完成一个可以启动这个包含DiscardServerHandler处理器服务的主方法。



Java代码
package org.jboss.netty.example.discard;

import java.net.InetSocketAddress;
import java.util.concurrent.Executors;

public class DiscardServer {

public static void main(String[] args) throws Exception {
ChannelFactory factory =
new NioServerSocketChannelFactory (
Executors.newCachedThreadPool(),
Executors.newCachedThreadPool());

ServerBootstrap bootstrap = new ServerBootstrap (factory);

DiscardServerHandler handler = new DiscardServerHandler();
ChannelPipeline pipeline = bootstrap.getPipeline();
pipeline.addLast("handler", handler);

bootstrap.setOption("child.tcpNoDelay", true);
bootstrap.setOption("child.keepAlive", true);

bootstrap.bind(new InetSocketAddress(8080));
}
}


代码说明


1)ChannelFactory 是一个创建和管理Channel通道及其相关资源的工厂接口，它处理所有的I/O请求并产生相应的I/O ChannelEvent通道事件。Netty 提供了多种 ChannelFactory 实现。这里我们需要实现一个服务端的例子，因此我们使用NioServerSocketChannelFactory实现。另一件需要注意的事情是这个工 厂并自己不负责创建I/O线程。你应当在其构造器中指定该工厂使用的线程池，这样做的好处是你获得了更高的控制力来管理你的应用环境中使用的线程，例如一 个包含了安全管理的应用服务。

2)ServerBootstrap 是一个设置服务的帮助类。你甚至可以在这个服务中直接设置一个Channel通道。然而请注意，这是一个繁琐的过程，大多数情况下并不需要这样做。

3)这里，我们将DiscardServerHandler处理器添加至默认的ChannelPipeline通道。任何时候当服务器接收到一个新的连 接，一个新的ChannelPipeline管道对象将被创建，并且所有在这里添加的ChannelHandler对象将被添加至这个新的 ChannelPipeline管道对象。这很像是一种浅拷贝操作（a shallow-copy operation）；所有的Channel通道以及其对应的ChannelPipeline实例将分享相同的DiscardServerHandler 实例。

4)你也可以设置我们在这里指定的这个通道实现的配置参数。我们正在写的是一个TCP/IP服务，因此我们运行设定一些socket选项，例如 tcpNoDelay和keepAlive。请注意我们在配置选项里添加的"child."前缀。这意味着这个配置项仅适用于我们接收到的通道实例，而不 是ServerSocketChannel实例。因此，你可以这样给一个ServerSocketChannel设定参数：
bootstrap.setOption("reuseAddress", true);

5)我们继续。剩下要做的是绑定这个服务使用的端口并且启动这个服务。这里，我们绑定本机所有网卡（NICs,network interface cards）上的8080端口。当然，你现在也可以对应不同的绑定地址多次调用绑定操作。

大功告成！现在你已经完成你的第一个基于Netty的服务端程序。

1.3. 查看接收到的数据


现在你已经完成了你的第一个服务端程序，我们需要测试它是否可以真正的工作。最简单的方法是使用telnet 命令。例如，你可以在命令行中输入“telnet localhost 8080 ”或其他类型参数。

然而，我们可以认为服务器在正常工作吗？由于这是一个丢球协议服务，所以实际上我们无法真正的知道。你最终将收不到任何回应。为了证明它在真正的工作，让我们修改代码打印其接收到的数据。
我们已经知道当完成数据的接收后将产生MessageEvent消息事件，并且也会触发messageReceived处理方法。所以让我在DiscardServerHandler处理器的messageReceived方法内增加一些代码。

Java代码
@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
ChannelBuffer buf = (ChannelBuffer) e.getMessage();
while(buf.readable()) {
System.out.println((char) buf.readByte());
}
}


代码说明

1) 基本上我们可以假定在socket的传输中消息类型总是ChannelBuffer。ChannelBuffer是Netty的一个基本数据结构，这个数 据结构存储了一个字节序列。ChannelBuffer类似于NIO的ByteBuffer，但是前者却更加的灵活和易于使用。例如，Netty允许你创 建一个由多个ChannelBuffer构建的复合ChannelBuffer类型，这样就可以减少不必要的内存拷贝次数。

2) 虽然ChannelBuffer有些类似于NIO的ByteBuffer，但强烈建议你参考Netty的API手册。学会如何正确的使用ChannelBuffer是无障碍使用Netty的关键一步。

如果你再次运行telnet命令，你将会看到你所接收到的数据。
抛弃协议服务的所有源代码均存放在在分发版的org.jboss.netty.example.discard包下。


1.4. 响应协议服务


目前，我们虽然使用了数据，但最终却未作任何回应。然而一般情况下，一个服务都需要回应一个请求。让我们实现ECHO协议 来学习如何完成一个客户请求的回应消息，ECHO协议规定要返回任何接收到的数据。

与我们上一节实现的抛弃协议服务唯一不同的地方是，这里需要返回所有的接收数据而不是仅仅打印在控制台之上。因此我们再次修改messageReceived方法就足够了。

Java代码
@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
Channel ch = e.getChannel();
ch.write(e.getMessage());
}
代码说明
1) 一个ChannelEvent通道事件对象自身存有一个和其关联的Channel对象引用。这个返回的Channel通道对象代表了这个接收 MessageEvent消息事件的连接（connection）。因此，我们可以通过调用这个Channel通道对象的write方法向远程节点写入返 回数据。

现在如果你再次运行telnet命令，你将会看到服务器返回的你所发送的任何数据。

相应服务的所有源代码存放在分发版的org.jboss.netty.example.echo包下。

1.5. 时间协议服务


这一节需要实现的协议是TIME协议 。这是一个与先前所介绍的不同的例子。这个例子里，服务端返回一个32位的整数消息，我们不接受请求中包含的任何数据并且当消息返回完毕后立即关闭连接。通过这个例子你将学会如何构建和发送消息，以及当完成处理后如何主动关闭连接。

因为我们会忽略接收到的任何数据而只是返回消息，这应当在建立连接后就立即开始。因此这次我们不再使用messageReceived方法，取而代之的是使用channelConnected方法。下面是具体的实现：



Java代码
package org.jboss.netty.example.time;

@ChannelPipelineCoverage("all")
public class TimeServerHandler extends SimpleChannelHandler {

@Override
public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
Channel ch = e.getChannel();

ChannelBuffer time = ChannelBuffers.buffer(4);
time.writeInt(System.currentTimeMillis() / 1000);

ChannelFuture f = ch.write(time);

f.addListener(new ChannelFutureListener() {
public void operationComplete(ChannelFuture future) {
Channel ch = future.getChannel();
ch.close();
}
});
}

@Override
public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) {
e.getCause().printStackTrace();
e.getChannel().close();
}
}

代码说明
1) 正如我们解释过的，channelConnected方法将在一个连接建立后立即触发。因此让我们在这个方法里完成一个代表当前时间（秒）的32位整数消息的构建工作。

2) 为了发送一个消息，我们需要分配一个包含了这个消息的buffer缓冲。因为我们将要写入一个32位的整数，因此我们需要一个4字节的 ChannelBuffer。ChannelBuffers是一个可以创建buffer缓冲的帮助类。除了这个buffer方 法，ChannelBuffers还提供了很多和ChannelBuffer相关的实用方法。更多信息请参考API手册。

另外，一个很不错的方法是使用静态的导入方式：
import static org.jboss.netty.buffer.ChannelBuffers.*;
...
ChannelBuffer dynamicBuf = dynamicBuffer(256);
ChannelBuffer ordinaryBuf = buffer(1024);

3) 像通常一样，我们需要自己构造消息。

但是打住，flip在哪？过去我们在使用NIO发送消息时不是常常需要调用 ByteBuffer.flip()方法吗？实际上ChannelBuffer之所以不需要这个方法是因为 ChannelBuffer有两个指针；一个对应读操作，一个对应写操作。当你向一个 ChannelBuffer写入数据的时候写指针的索引值便会增加，但与此同时读指针的索引值不会有任何变化。读写指针的索引值分别代表了这个消息的开 始、结束位置。

与之相应的是，NIO的buffer缓冲没有为我们提供如此简洁的一种方法，除非你调用它的flip方法。因此，当你忘记调用flip方法而引起发送错误 时，你便会陷入困境。这样的错误不会再Netty中发生，因为我们对应不同的操作类型有不同的指针。你会发现就像你已习惯的这样过程变得更加容易—一种没 有flippling的体验！

另一点需要注意的是这个写方法返回了一个ChannelFuture对象。一个ChannelFuture 对象代表了一个尚未发生的I/O操作。这意味着，任何已请求的操作都可能是没有被立即执行的，因为在Netty内部所有的操作都是异步的。例如，下面的代 码可能会关闭一 个连接，这个操作甚至会发生在消息发送之前：

Channel ch = ...;
ch.write(message);
ch.close();

因此，你需要这个write方法返回的ChannelFuture对象，close方法需要等待写操作异步完成之后的ChannelFuture通知/监听触发。需要注意的是，关闭方法仍旧不是立即关闭一个连接，它同样也是返回了一个ChannelFuture对象。

4) 在写操作完成之后我们又如何得到通知？这个只需要简单的为这个返回的ChannelFuture对象增加一个ChannelFutureListener 即可。在这里我们创建了一个匿名ChannelFutureListener对象，在这个ChannelFutureListener对象内部我们处理了 异步操作完成之后的关闭操作。

另外，你也可以通过使用一个预定义的监听类来简化代码。
f.addListener(ChannelFutureListener.CLOSE);


1.6. 时间协议服务客户端


不同于DISCARD和ECHO协议服务，我们需要一个时间协议服务的客户端，因为人们无法直接将一个32位的二进制数据转换一个日历时间。在这一节我们将学习如何确保服务器端工作正常，以及如何使用Netty完成客户端的开发。

使用Netty开发服务器端和客户端代码最大的不同是要求使用不同的Bootstrap及ChannelFactory。请参照以下的代码：

Java代码
package org.jboss.netty.example.time;

import java.net.InetSocketAddress;
import java.util.concurrent.Executors;

public class TimeClient {

public static void main(String[] args) throws Exception {
String host = args[0];
int port = Integer.parseInt(args[1]);

ChannelFactory factory =
new NioClientSocketChannelFactory (
Executors.newCachedThreadPool(),
Executors.newCachedThreadPool());

ClientBootstrap bootstrap = new ClientBootstrap (factory);

TimeClientHandler handler = new TimeClientHandler();
bootstrap.getPipeline().addLast("handler", handler);

bootstrap.setOption("tcpNoDelay" , true);
bootstrap.setOption("keepAlive", true);

bootstrap.connect (new InetSocketAddress(host, port));
}
}
代码说明
1) 使用NioClientSocketChannelFactory而不是NioServerSocketChannelFactory来创建客户端的Channel通道对象。

2) 客户端的ClientBootstrap对应ServerBootstrap。

3) 请注意，这里不存在使用“child.”前缀的配置项，客户端的SocketChannel实例不存在父级Channel对象。

4) 我们应当调用connect连接方法，而不是之前的bind绑定方法。

正如你所看到的，这与服务端的启动过程是完全不一样的。ChannelHandler又该如何实现呢？它应当负责接收一个32位的整数，将其转换为可读的格式后，打印输出时间，并关闭这个连接。



Java代码
package org.jboss.netty.example.time;

import java.util.Date;

@ChannelPipelineCoverage("all")
public class TimeClientHandler extends SimpleChannelHandler {

@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
ChannelBuffer buf = (ChannelBuffer) e.getMessage();
long currentTimeMillis = buf.readInt() * 1000L;
System.out.println(new Date(currentTimeMillis));
e.getChannel().close();
}

@Override
public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) {
e.getCause().printStackTrace();
e.getChannel().close();
}
}

这看起来很是简单，与服务端的实现也并未有什么不同。然而，这个处理器却时常会因为抛出IndexOutOfBoundsException异常而拒绝工作。我们将在下一节讨论这个问题产生的原因。

1.7. 流数据的传输处理



1.7.1. Socket Buffer的缺陷


对于例如TCP/IP这种基于流的传输协议实现，接收到的数据会被存储在socket的接受缓冲区内。不幸的是，这种基于流的传输缓冲区并不是一个包队 列，而是一个字节队列。这意味着，即使你以两个数据包的形式发送了两条消息，操作系统却不会把它们看成是两条消息，而仅仅是一个批次的字节序列。因此，在 这种情况下我们就无法保证收到的数据恰好就是远程节点所发送的数据。例如，让我们假设一个操作系统的TCP/IP堆栈收到了三个数据包：



+-----+-----+-----+
| ABC | DEF | GHI |
+-----+-----+-----+

由于这种流传输协议的普遍性质，在你的应用中有较高的可能会把这些数据读取为另外一种形式：



+----+-------+---+---+
| AB | CDEFG | H | I |
+----+-------+---+---+


因此对于数据的接收方，不管是服务端还是客户端，应当重构这些接收到的数据，让其变成一种可让你的应用逻辑易于理解的更有意义的数据结构。在上面所述的这个例子中，接收到的数据应当重构为下面的形式：



+-----+-----+-----+
| ABC | DEF | GHI |
+-----+-----+-----+

1.7.2. 第一种方案


现在让我们回到时间协议服务客户端的例子中。我们在这里遇到了同样的问题。一个32位的整数是一个非常小的数据量，因此它常常不会被切分在不同的数据段内。然而，问题是它确实可以被切分在不同的数据段内，并且这种可能性随着流量的增加而提高。

最简单的方案是在程序内部创建一个可准确接收4字节数据的累积性缓冲。下面的代码是修复了这个问题后的TimeClientHandler实现。



Java代码
package org.jboss.netty.example.time;

import static org.jboss.netty.buffer.ChannelBuffers.*;

import java.util.Date;

@ChannelPipelineCoverage("one")
public class TimeClientHandler extends SimpleChannelHandler {

private final ChannelBuffer buf = dynamicBuffer();

@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
ChannelBuffer m = (ChannelBuffer) e.getMessage();
buf.writeBytes(m);

if (buf.readableBytes() >= 4) {
long currentTimeMillis = buf.readInt() * 1000L;
System.out.println(new Date(currentTimeMillis));
e.getChannel().close();
}
}

@Override
public void exceptionCaught(ChannelHandlerContext ctx, ExceptionEvent e) {
e.getCause().printStackTrace();
e.getChannel().close();
}
}


代码说明

1) 这一次我们使用“one”做为ChannelPipelineCoverage的注解值。这是由于这个修改后的TimeClientHandler不在不 在内部保持一个buffer缓冲，因此这个TimeClientHandler实例不可以再被多个Channel通道或ChannelPipeline共 享。否则这个内部的buffer缓冲将无法缓冲正确的数据内容。

2) 动态的buffer缓冲也是ChannelBuffer的一种实现，其拥有动态增加缓冲容量的能力。当你无法预估消息的数据长度时，动态的buffer缓冲是一种很有用的缓冲结构。

3) 首先，所有的数据将会被累积的缓冲至buf容器。

4) 之后，这个处理器将会检查是否收到了足够的数据然后再进行真实的业务逻辑处理，在这个例子中需要接收4字节数据。否则，Netty将重复调用messageReceived方法，直至4字节数据接收完成。

这里还有另一个地方需要进行修改。你是否还记得我们把TimeClientHandler实例添加到了这个ClientBootstrap实例的默 认ChannelPipeline管道里？这意味着同一个TimeClientHandler实例将被多个Channel通道共享，因此接受的数据也将受 到破坏。为了给每一个Channel通道创建一个新的TimeClientHandler实例，我们需要实现一个 ChannelPipelineFactory管道工厂：

Java代码
package org.jboss.netty.example.time;

public class TimeClientPipelineFactory implements ChannelPipelineFactory {

public ChannelPipeline getPipeline() {
ChannelPipeline pipeline = Channels.pipeline();
pipeline.addLast("handler", new TimeClientHandler());
return pipeline;
}
}

现在，我们需要把TimeClient下面的代码片段：

Java代码
TimeClientHandler handler = new TimeClientHandler();
bootstrap.getPipeline().addLast("handler", handler);

替换为：

Java代码
bootstrap.setPipelineFactory(new TimeClientPipelineFactory());

虽然这看上去有些复杂，并且由于在TimeClient内部我们只创建了一个连接（connection），因此我们在这里确实没必要引入TimeClientPipelineFactory实例。

然而，当你的应用变得越来越复杂，你就总会需要实现自己的ChannelPipelineFactory，这个管道工厂将会令你的管道配置变得更加具有灵活性。

1.7.3. 第二种方案



虽然第二种方案解决了时间协议客户端遇到的问题，但是这个修改后的处理器实现看上去却不再那么简洁。设想一种更为复杂的，由多个可变长度字段组成的协议。你的ChannelHandler实现将变得越来越难以维护。

正如你已注意到的，你可以为一个ChannelPipeline添加多个ChannelHandler，因此，为了减小应用的复杂性，你可以把这个臃肿的 ChannelHandler切分为多个独立的模块单元。例如，你可以把TimeClientHandler切分为两个独立的处理器：

TimeDecoder，解决数据分段的问题。
TimeClientHandler，原始版本的实现。
幸运的是，Netty提供了一个可扩展的类，这个类可以直接拿过来使用帮你完成TimeDecoder的开发：

Java代码
package org.jboss.netty.example.time;


public class TimeDecoder extends FrameDecoder {

@Override
protected Object decode(
ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) {

if (buffer.readableBytes() < 4) {
return null;
}

return buffer.readBytes(4);
}
}


代码说明
1) 这里不再需要使用ChannelPipelineCoverage的注解，因为FrameDecoder总是被注解为“one”。

2) 当接收到新的数据后，FrameDecoder会调用decode方法，同时传入一个FrameDecoder内部持有的累积型buffer缓冲。

3) 如果decode返回null值，这意味着还没有接收到足够的数据。当有足够数量的数据后FrameDecoder会再次调用decode方法。

4) 如果decode方法返回一个非空值，这意味着decode方法已经成功完成一条信息的解码。FrameDecoder将丢弃这个内部的累计型缓冲。请注 意你不需要对多条消息进行解码，FrameDecoder将保持对decode方法的调用，直到decode方法返回非空对象。

如果你是一个勇于尝试的人，你或许应当使用ReplayingDecoder，ReplayingDecoder更加简化了解码的过程。为此你需要查看API手册获得更多的帮助信息。

Java代码
package org.jboss.netty.example.time;

public class TimeDecoder extends ReplayingDecoder<VoidEnum> {

@Override
protected Object decode(
ChannelHandlerContext ctx, Channel channel,
ChannelBuffer buffer, VoidEnum state) {

return buffer.readBytes(4);
}
}

此外，Netty还为你提供了一些可以直接使用的decoder实现，这些decoder实现不仅可以让你非常容易的实现大多数协议，并且还会帮你避免某些臃肿、难以维护的处理器实现。请参考下面的代码包获得更加详细的实例：

org.jboss.netty.example.factorial for a binary protocol, and
org.jboss.netty.example.telnet for a text line-based protocol
1.8. 使用POJO代替ChannelBuffer


目前为止所有的实例程序都是使用ChannelBuffer做为协议消息的原始数据结构。在这一节，我们将改进时间协议服务的客户/服务端实现，使用POJO 而不是ChannelBuffer做为协议消息的原始数据结构。

在你的ChannelHandler实现中使用POJO的优势是很明显的；从你的ChannelHandler实现中分离从ChannelBuffer获 取数据的代码，将有助于提高你的ChannelHandler实现的可维护性和可重用性。在时间协议服务的客户/服务端代码中，直接使用 ChannelBuffer读取一个32位的整数并不是一个主要的问题。然而，你会发现，当你试图实现一个真实的协议的时候，这种代码上的分离是很有必要 的。

首先，让我们定义一个称之为UnixTime的新类型。

Java代码
package org.jboss.netty.example.time;

import java.util.Date;

public class UnixTime {
private final int value;

public UnixTime(int value) {
this.value = value;
}

public int getValue() {
return value;
}

@Override
public String toString() {
return new Date(value * 1000L).toString();
}
}

现在让我们重新修改TimeDecoder实现，让其返回一个UnixTime，而不是一个ChannelBuffer。

Java代码
@Override
protected Object decode(
ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) {
if (buffer.readableBytes() < 4) {
return null;
}

return new UnixTime(buffer.readInt());
}

FrameDecoder和ReplayingDecoder允许你返回一个任何类型的对象。如果它们仅允许返回一个ChannelBuffer类 型的对象，我们将不得不插入另一个可以从ChannelBuffer对象转换 为UnixTime对象的ChannelHandler实现。


有了这个修改后的decoder实现，这个TimeClientHandler便不会再依赖ChannelBuffer。

Java代码
@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
UnixTime m = (UnixTime) e.getMessage();
System.out.println(m);
e.getChannel().close();
}

更加简单优雅了，不是吗？同样的技巧也可以应用在服务端，让我们现在更新TimeServerHandler的实现：

Java代码
@Override
public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
UnixTime time = new UnixTime(System.currentTimeMillis() / 1000);
ChannelFuture f = e.getChannel().write(time);
f.addListener(ChannelFutureListener.CLOSE);
}

现在剩下的唯一需要修改的部分是这个ChannelHandler实现，这个ChannelHandler实现需要把一个UnixTime对象重新 转换为一个ChannelBuffer。但这却已是相当简单了，因为当你对消息进行编码的时候你不再需要处理数据包的拆分及组装。

Java代码
package org.jboss.netty.example.time;

import static org.jboss.netty.buffer.ChannelBuffers.*;

@ChannelPipelineCoverage("all")
public class TimeEncoder extends SimpleChannelHandler {

public void writeRequested(ChannelHandlerContext ctx, MessageEvent e) {
UnixTime time = (UnixTime) e.getMessage();

ChannelBuffer buf = buffer(4);
buf.writeInt(time.getValue());

Channels.write(ctx, e.getFuture(), buf);
}
}

代码说明

1) 因为这个encoder是无状态的，所以其使用的ChannelPipelineCoverage注解值是“all”。实际上，大多数encoder实现都是无状态的。

2) 一个encoder通过重写writeRequested方法来实现对写操作请求的拦截。不过请注意虽然这个writeRequested方法使用了和 messageReceived方法一样的MessageEvent参数，但是它们却分别对应了不同的解释。一个ChannelEvent事件可以既是一 个上升流事件（upstream event）也可以是一个下降流事件（downstream event），这取决于事件流的方向。例如：一个MessageEvent消息事件可以作为一个上升流事件（upstream event）被messageReceived方法调用，也可以作为一个下降流事件（downstream event）被writeRequested方法调用。请参考API手册获得上升流事件（upstream event）和下降流事件（downstream event）的更多信息。

3) 一旦完成了POJO和ChannelBuffer转换，你应当确保把这个新的buffer缓冲转发至先前的 ChannelDownstreamHandler处理，这个下降通道的处理器由某个ChannelPipeline管理。Channels提供了多个可 以创建和发送ChannelEvent事件的帮助方法。在这个例子中，Channels.write(...)方法创建了一个新的 MessageEvent事件，并把这个事件发送给了先前的处于某个ChannelPipeline内的 ChannelDownstreamHandler处理器。

另外，一个很不错的方法是使用静态的方式导入Channels类：

import static org.jboss.netty.channel.Channels.*;
...
ChannelPipeline pipeline = pipeline();
write(ctx, e.getFuture(), buf);
fireChannelDisconnected(ctx);


最后的任务是把这个TimeEncoder插入服务端的ChannelPipeline，这是一个很简单的步骤。

1.9. 关闭你的应用


如果你运行了TimeClient，你肯定可以注意到，这个应用并没有自动退出而只是在那里保持着无意义的运行。跟踪堆栈记录你可以发现，这里有一些运行 状态的I/O线程。为了关闭这些I/O线程并让应用优雅的退出，你需要释放这些由ChannelFactory分配的资源。

一个典型的网络应用的关闭过程由以下三步组成：

关闭负责接收所有请求的server socket。
关闭所有客户端socket或服务端为响应某个请求而创建的socket。
释放ChannelFactory使用的所有资源。
为了让TimeClient执行这三步，你需要在TimeClient.main()方法内关闭唯一的客户连接以及ChannelFactory使用的所有资源，这样做便可以优雅的关闭这个应用。

Java代码
package org.jboss.netty.example.time;

public class TimeClient {
public static void main(String[] args) throws Exception {
...
ChannelFactory factory = ...;
ClientBootstrap bootstrap = ...;
...
ChannelFuture future = bootstrap.connect(...);
future.awaitUninterruptible();
if (!future.isSuccess()) {
future.getCause().printStackTrace();
}
future.getChannel().getCloseFuture().awaitUninterruptibly();
factory.releaseExternalResources();
}
}
代码说明
1) ClientBootstrap对象的connect方法返回一个ChannelFuture对象，这个ChannelFuture对象将告知这个连接操 作的成功或失败状态。同时这个ChannelFuture对象也保存了一个代表这个连接操作的Channel对象引用。

2) 阻塞式的等待，直到ChannelFuture对象返回这个连接操作的成功或失败状态。

3) 如果连接失败，我们将打印连接失败的原因。如果连接操作没有成功或者被取消，ChannelFuture对象的getCause()方法将返回连接失败的原因。

4) 现在，连接操作结束，我们需要等待并且一直到这个Channel通道返回的closeFuture关闭这个连接。每一个Channel都可获得自己的closeFuture对象，因此我们可以收到通知并在这个关闭时间点执行某种操作。

并且即使这个连接操作失败，这个closeFuture仍旧会收到通知，因为这个代表连接的 Channel对象将会在连接操作失败后自动关闭。

5) 在这个时间点，所有的连接已被关闭。剩下的唯一工作是释放ChannelFactory通道工厂使用的资源。这一步仅需要调用 releaseExternalResources()方法即可。包括NIO Secector和线程池在内的所有资源将被自动的关闭和终止。

关闭一个客户端应用是很简单的，但又该如何关闭一个服务端应用呢？你需要释放其绑定的端口并关闭所有接受和打开的连接。为了做到这一点，你需要使用一种数据结构记录所有的活动连接，但这却并不是一件容易的事。幸运的是，这里有一种解决方案，ChannelGroup。

ChannelGroup是Java 集合 API的一个特有扩展，ChannelGroup内部持有所有打开状态的Channel通道。如果一个Channel通道对象被加入到 ChannelGroup，如果这个Channel通道被关闭，ChannelGroup将自动移除这个关闭的Channel通道对象。此外，你还可以对 一个ChannelGroup对象内部的所有Channel通道对象执行相同的操作。例如，当你关闭服务端应用时你可以关闭一个ChannelGroup 内部的所有Channel通道对象。

为了记录所有打开的socket，你需要修改你的TimeServerHandler实现，将一个打开的Channel通道加入全局的ChannelGroup对象，TimeServer.allChannels:

Java代码
@Override
public void channelOpen(ChannelHandlerContext ctx, ChannelStateEvent e) {
TimeServer.allChannels.add(e.getChannel());
}
代码说明
是的，ChannelGroup是线程安全的。

现在，所有活动的Channel通道将被自动的维护，关闭一个服务端应用有如关闭一个客户端应用一样简单。

Java代码
package org.jboss.netty.example.time;

public class TimeServer {

static final ChannelGroup allChannels = new DefaultChannelGroup("time-server" );

public static void main(String[] args) throws Exception {
...
ChannelFactory factory = ...;
ServerBootstrap bootstrap = ...;
...
Channel channel = bootstrap.bind(...);
allChannels.add(channel);
waitForShutdownCommand();
ChannelGroupFuture future = allChannels.close();
future.awaitUninterruptibly();
factory.releaseExternalResources();
}
}
代码说明
1) DefaultChannelGroup需要一个组名作为其构造器参数。这个组名仅是区分每个ChannelGroup的一个标示。

2) ServerBootstrap对象的bind方法返回了一个绑定了本地地址的服务端Channel通道对象。调用这个Channel通道的close()方法将释放这个Channel通道绑定的本地地址。

3) 不管这个Channel对象属于服务端，客户端，还是为响应某一个请求创建，任何一种类型的Channel对象都会被加入ChannelGroup。因此，你尽可在关闭服务时关闭所有的Channel对象。

4) waitForShutdownCommand()是一个想象中等待关闭信号的方法。你可以在这里等待某个客户端的关闭信号或者JVM的关闭回调命令。

5) 你可以对ChannelGroup管理的所有Channel对象执行相同的操作。在这个例子里，我们将关闭所有的通道，这意味着绑定在服务端特定地址的 Channel通道将解除绑定，所有已建立的连接也将异步关闭。为了获得成功关闭所有连接的通知，close()方法将返回一个 ChannelGroupFuture对象，这是一个类似ChannelFuture的对象。

1.10. 总述


在这一章节，我们快速浏览并示范了如何使用Netty开发网络应用。下一章节将涉及更多的问题。同时请记住，为了帮助你以及能够让Netty基于你的回馈得到持续的改进和提高，Netty社区 将永远欢迎你的问题及建议。



第二章. 架构总览

在这个章节，我们将阐述Netty提供的核心功能以及在此基础之上如何构建一个完备的网络应用。

2.1. 丰富的缓冲实现


Netty使用自建的buffer API，而不是使用NIO的ByteBuffer来代表一个连续的字节序列。与ByteBuffer相比这种方式拥有明显的优势。Netty使用新的 buffer类型ChannelBuffer，ChannelBuffer被设计为一个可从底层解决ByteBuffer问题，并可满足日常网络应用开发 需要的缓冲类型。这些很酷的特性包括：



如果需要，允许使用自定义的缓冲类型。
复合缓冲类型中内置的透明的零拷贝实现。
开箱即用的动态缓冲类型，具有像StringBuffer一样的动态缓冲能力。
不再需要调用的flip()方法。
正常情况下具有比ByteBuffer更快的响应速度。
更多信息请参考：org.jboss.netty.buffer package description

2.2. 统一的异步 I/O API


传统的Java I/O API在应对不同的传输协议时需要使用不同的类型和方法。例如：java.net.Socket 和 java.net.DatagramSocket它们并不具有相同的超类型，因此，这就需要使用不同的调用方式执行socket操作。

这种模式上的不匹配使得在更换一个网络应用的传输协议时变得繁杂和困难。由于（Java I/O API）缺乏协议间的移植性，当你试图在不修改网络传输层的前提下增加多种协议的支持，这时便会产生问题。并且理论上讲，多种应用层协议可运行在多种传输 层协议之上例如TCP/IP,UDP/IP,SCTP和串口通信。

让这种情况变得更糟的是，Java新的I/O（NIO）API与原有的阻塞式的I/O（OIO）API并不兼容，NIO.2(AIO)也是如此。由于所有的API无论是在其设计上还是性能上的特性都与彼此不同，在进入开发阶段，你常常会被迫的选择一种你需要的API。

例如，在用户数较小的时候你可能会选择使用传统的OIO(Old I/O) API，毕竟与NIO相比使用OIO将更加容易一些。然而，当你的业务呈指数增长并且服务器需要同时处理成千上万的客户连接时你便会遇到问题。这种情况下 你可能会尝试使用NIO，但是复杂的NIO Selector编程接口又会耗费你大量时间并最终会阻碍你的快速开发。

Netty有一个叫做Channel的统一的异步I/O编程接口，这个编程接口抽象了所有点对点的通信操作。也就是说，如果你的应用是基于Netty的某 一种传输实现，那么同样的，你的应用也可以运行在Netty的另一种传输实现上。Netty提供了几种拥有相同编程接口的基本传输实现：



NIO-based TCP/IP transport (See org.jboss.netty.channel.socket.nio),
OIO-based TCP/IP transport (See org.jboss.netty.channel.socket.oio),
OIO-based UDP/IP transport, and
Local transport (See org.jboss.netty.channel.local).
切换不同的传输实现通常只需对代码进行几行的修改调整，例如选择一个不同的ChannelFactory实现。

此外，你甚至可以利用新的传输实现没有写入的优势，只需替换一些构造器的调用方法即可，例如串口通信。而且由于核心API具有高度的可扩展性，你还可以完成自己的传输实现。

2.3. 基于拦截链模式的事件模型


一个定义良好并具有扩展能力的事件模型是事件驱动开发的必要条件。Netty具有定义良好的I/O事件模型。由于严格的层次结构区分了不同的事件类型，因 此Netty也允许你在不破坏现有代码的情况下实现自己的事件类型。这是与其他框架相比另一个不同的地方。很多NIO框架没有或者仅有有限的事件模型概 念；在你试图添加一个新的事件类型的时候常常需要修改已有的代码，或者根本就不允许你进行这种扩展。

在一个ChannelPipeline内部一个ChannelEvent被一组ChannelHandler处理。这个管道是拦截过滤器 模式的一种高级形式的实现，因此对于一个事件如何被处理以及管道内部处理器间的交互过程，你都将拥有绝对的控制力。例如，你可以定义一个从socket读取到数据后的操作：

Java代码
public class MyReadHandler implements SimpleChannelHandler {
public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
Object message = evt.getMessage();
// Do something with the received message.
...

// And forward the event to the next handler.
ctx.sendUpstream(evt);
}
}

同时你也可以定义一种操作响应其他处理器的写操作请求：

Java代码
public class MyWriteHandler implements SimpleChannelHandler {
public void writeRequested(ChannelHandlerContext ctx, MessageEvent evt) {
Object message = evt.getMessage();
// Do something with the message to be written.
...

// And forward the event to the next handler.
ctx.sendDownstream(evt);
}
}

有关事件模型的更多信息，请参考API文档ChannelEvent和ChannelPipeline部分。

2.4. 适用快速开发的高级组件


上述所提及的核心组件已经足够实现各种类型的网络应用，除此之外，Netty也提供了一系列的高级组件来加速你的开发过程。

2.4.1. Codec框架


就像“1.8. 使用POJO代替ChannelBuffer”一节所展示的那样，从业务逻辑代码中分离协议处理部分总是一个很不错的想法。然而如果一切从零开始便会遭遇 到实现上的复杂性。你不得不处理分段的消息。一些协议是多层的（例如构建在其他低层协议之上的协议）。一些协议过于复杂以致难以在一台主机（single state machine）上实现。

因此，一个好的网络应用框架应该提供一种可扩展，可重用，可单元测试并且是多层的codec框架，为用户提供易维护的codec代码。

Netty提供了一组构建在其核心模块之上的codec实现，这些简单的或者高级的codec实现帮你解决了大部分在你进行协议处理开发过程会遇到的问题，无论这些协议是简单的还是复杂的，二进制的或是简单文本的。

2.4.2. SSL / TLS 支持


不同于传统阻塞式的I/O实现，在NIO模式下支持SSL功能是一个艰难的工作。你不能只是简单的包装一下流数据并进行加密或解密工作，你不得不借助于 javax.net.ssl.SSLEngine，SSLEngine是一个有状态的实现，其复杂性不亚于SSL自身。你必须管理所有可能的状态，例如密 码套件，密钥协商（或重新协商），证书交换以及认证等。此外，与通常期望情况相反的是SSLEngine甚至不是一个绝对的线程安全实现。

在Netty内部，SslHandler封装了所有艰难的细节以及使用SSLEngine可能带来的陷阱。你所做的仅是配置并将该SslHandler插入到你的ChannelPipeline中。同样Netty也允许你实现像StartTlS 那样所拥有的高级特性，这很容易。

2.4.3. HTTP实现


HTTP无疑是互联网上最受欢迎的协议，并且已经有了一些例如Servlet容器这样的HTTP实现。因此，为什么Netty还要在其核心模块之上构建一套HTTP实现？

与现有的HTTP实现相比Netty的HTTP实现是相当与众不同的。在HTTP消息的低层交互过程中你将拥有绝对的控制力。这是因为Netty的 HTTP实现只是一些HTTP codec和HTTP消息类的简单组合，这里不存在任何限制——例如那种被迫选择的线程模型。你可以随心所欲的编写那种可以完全按照你期望的工作方式工作 的客户端或服务器端代码。这包括线程模型，连接生命期，快编码，以及所有HTTP协议允许你做的，所有的一切，你都将拥有绝对的控制力。

由于这种高度可定制化的特性，你可以开发一个非常高效的HTTP服务器，例如：

要求持久化链接以及服务器端推送技术的聊天服务（e.g. Comet ）
需要保持链接直至整个文件下载完成的媒体流服务（e.g. 2小时长的电影）
需要上传大文件并且没有内存压力的文件服务（e.g. 上传1GB文件的请求）
支持大规模mash-up应用以及数以万计连接的第三方web services异步处理平台
2.4.4. Google Protocol Buffer 整合


Google Protocol Buffers 是快速实现一个高效的二进制协议的理想方案。通过使用ProtobufEncoder和ProtobufDecoder，你可以把Google Protocol Buffers 编译器 (protoc)生成的消息类放入到Netty的codec实现中。请参考“LocalTime ”实例，这个例子也同时显示出开发一个由简单协议定义 的客户及服务端是多么的容易。

2.5. 总述
在这一章节，我们从功能特性的角度回顾了Netty的整体架构。Netty有一个简单却不失强大的架构。这个架构由三部分组成——缓冲（buffer）， 通道（channel），事件模型（event model）——所有的高级特性都构建在这三个核心组件之上。一旦你理解了它们之间的工作原理，你便不难理解在本章简要提及的更多高级特性。

你可能对Netty的整体架构以及每一部分的工作原理仍旧存有疑问。如果是这样，最好的方式是告诉我们 应该如何改进这份指南 bug描述:
    parseInt("08")=0;
    parseInt("09")=0;

这里先回顾一下parseInt的函数声明:

 ‘01’到’07’，按8进制或10进制解析会得到相同的结果。 而’08’，’09’按8进制解析会得到’0’，因为’8’、’9’在8进制中是非法字符，不会被解析。由此导致上述的bug。
找到问题根源，修复就变得很简单了，显示指定radix为10.
parseInt("08",10);

在本教程中，我们将看到使用Eclipse调试Java应用程序。调试可以帮助我们识别和解决应用程序中的缺陷。我们将重点放在运行时间的问题，而不是编译时错误。有提供像gdb的命令行调试器。在本教程中，我们将集中在基于GUI的调试，我们把我们最喜爱的IDE Eclipse来运行，通过本教程。虽然我们说的Eclipse，点大多是通用的，适用于调试使用的IDE像NetBeans。

在看这篇文章前，我推荐你看一下Eclipse 快捷键手册，你也可以到这儿：下载PDF文件我的eclipse版本是4.2 Juno。

0.三点特别提醒：

• 不要使用System.out.println作为调试工具
• 启用所有组件的详细的日志记录级别
• 使用一个日志分析器来阅读日志

[

（System.out.println()对开发人员来说，有时候也许可以是一种调试手段，但是项目一旦完成他就没有什么用途了，就变成垃圾了，得必须注释或删除掉，这样会比较麻烦。启用所有组件的详细日志记录级别，运用日志分析器来记录详细系统运行状态,这对后期网站的优化和维护会有很多作用。）这仅仅是个人理解，仅供参考！

]

1.条件断点

想象一下我们平时如何添加断点，通常的做法是双击行号的左边。在debug视图中，BreakPoint View将所有断点都列出来，但是我们可以添加一个boolean类型的条件来决定断点是否被跳过。如果条件为真，在断点处程序将停止，否则断点被跳过，程序继续执行。

2.异常断点

在断点view中有一个看起来像J！的按钮，我们可以使用它添加一个基于异常的断点，例如我们希望当NullPointerException抛出的时候程序暂停，我们可以这样:

3.观察点

这是一个很好的功能，他允许当一个选定的属性被访问或者被更改的时候程序执行暂停，并进行debug。最简单的办法是在类中声明成员变量的语句行号左边双击，就可以加入一个观察点。

4.查看变量

在选中的变量上使用Ctrl+Shift+d 或者 Ctrl+Shift+i可以查看变量值，另外我们还可以在Expressions View中添加监视。

5.更改变量的值

我们可以在Debug的时候改变其中变量的值。在Variables View中可以按下图所示操作。

6.在主方法停止

在Run/Debug设置中，我们可以按如下图所示的启用这个特性。程序将会在main方法的第一行停住

7.环境变量

我们可以很方便的在Edit Conriguration对话框中添加环境变量

8.跳出函数到选定层

这个功能非常酷，是我第二个非常喜欢的功能，Drop to frame就是说，可以重新跳到当前方法的开始处重新执行，并且所有上下文变量的值也回到那个时候。不一定是当前方法，可以点击当前调用栈中的任何一个frame跳到那里（除了最开始的那个frame）。主要用途是所有变量状态快速恢复到方法开始时候的样子重新执行一遍，即可以一遍又一遍地在那个你关注的上下文中进行多次调试（结合改变变量值等其它功能），而不用重来一遍调试到哪里了。当然，原来执行过程中产生的副作用是不可逆的（比如你往数据库中插入了一条记录）。

9.分步过滤

当我们在调试的时候摁F5将进入方法的内部，但这有个缺点有的时候可能会进入到一些库的内部（例如JDK），可能并不是我们想要的，我们可以在Preferences中添加一个过滤器，排除指定的包。

10.跳入，跳过和返回

<a href="itms-services://?action=download-manifest&amp;url=http://test1.gc73.com.cn/hoho.plist"> 

http://test1.gc73.com.cn/hoho.plist 文件格式如下

<?xml version="1.0" encoding="gbk"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> 	<key>items</key> 	<array> 		<dict> 			<key>assets</key> 			<array> 				<dict> 					<key>kind</key> 					<string>software-package</string> 					<key>url</key> 					<string>http://dlx1.gc73.com/pokerddzV2.1-7.20.iPad.ipa</string> 				</dict> 				<dict> 					<key>kind</key> 					<string>full-size-image</string> 					<key>needs-shine</key> 					<false/> 					<key>url</key> 					<string>http://test1.gc73.com.cn/ipad_tmp.png</string> 				</dict> 				<dict> 					<key>kind</key> 					<string>display-image</string> 					<key>needs-shine</key> 					<false/> 					<key>url</key> 					<string>http://test1.gc73.com.cn/ipad_tmp.png</string> 				</dict> 			</array> 			<key>metadata</key> 			<dict> 				<key>bundle-identifier</key> 				<string>com.pokercity.fightlordiPad</string> 				<key>kind</key> 				<string>software</string> 				<key>subtitle</key> 				<string>咱的测试</string> 				<key>title</key> 				<string>咱的测试(越狱版)</string> 			</dict> 		</dict> 	</array> </dict> </plist>

    VisualVM是Sun的一个OpenJDK项目，其目的在于为Java应用创建一个整套的问题解决工具。它集成了多个JDK命令工具的一个可视化工具，它主要用来监控JVM的运行情况，可以用它来查看和浏览Heap Dump、Thread Dump、内存对象实例情况、GC执行情况、CPU消耗以及类的装载情况。 Java开发人员可以使用 VisualVM创建必要信息的日志，系统管理人员可用来监控及控制Java应用程序在网络中的运行状况。 
   下载页面 : https://visualvm.dev.java.net/download.html

    文档地址 : https://visualvm.dev.java.net/docindex.html

    入门文档 : https://visualvm.dev.java.net/zh_CN/gettingstarted.html

    

---

    安装插件
    通过安装 VisualVM 更新中心提供的插件，可以向 VisualVM 添加功能。
    1. 从主菜单中选择“工具”>“插件”。
    2. 在“可用插件”标签中，选中该插件的“安装”复选框。单击“安装”。
    3. 逐步完成插件安装程序。
    

---

    功能    
    1. 概述
        查看jvm信息及系统配置
    

    2. 监视
        了解项目运动的概况
    

    3. visual gc
        可以看到内存gc的详细情况
        

---

    远程监控    
    1. 通过jstatd启动RMI服务
        配置java安全访问，将如下的代码存为文件 jstatd.all.policy，放到JAVA_HOME/bin中，其内容如下，
        grant codebase "file:${java.home}/../lib/tools.jar" {

               permission java.security.AllPermission;

          };
            
          执行命令jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=192.168.1.8 &(192.168.1.8  为你服务器的ip地址,&表示用守护线程的方式运行)
          jstatd命令详解 :http://hzl7652.iteye.com/blog/1183182 
         
          打开jvisualvm, 右键Remort,选择 "Add Remort Host..."，在弹出框中输入你的远端IP,比如192.168.1.8. 连接成功.
    
    2. 配置JMX管理tomcat
        打开Tomcat的bin/catalina.bat，如果为linux或unix系统，则为catalina.sh文件 。 
           无限制访问 
           

          (jmxremote.access 在JAVA_HOME\jre\lib\management下有模板)
         jmxremote.access 中显示
         monitorRole   readonly         
        jmxremote.password中显示
        monitorRole  QED            (QED为密码)

 

    以字母或下划线开头!
    今天找一个css的加载问题,class已经被浏览器加载到,但是属性值一直不显示出来,几经查找才发现className以数字开头命名的,导致浏览器不认可,整一个悲剧     最近在进行MyEclipse启动速度优化,优化发现MyEclipse报这个错误,关掉它的提示后不影响正常的使用.

    用visualvm监控发现heap memory正常运转,查看了下配置参数,发现这个参数-XX:+DisableExplicitGC(禁止system.gc()的调用,gc过程完全有jvm控制),怀疑他就是报错的原因,去掉后一切正常.估计是MyEclipse在发现heap memory不足是显示调用了gc方法,然后gc方法不被jvm接受,当内存达到MyEclipse的报警值时报错提醒 



     摘要: http://hain.iteye.com/blog/150875web.xml文件中配置<mime-mapping>下载文件类型TOMCAT在默认情况下下载.rar的文件是把文件当作text打开,以至于IE打开RAR文件为乱码,如果遇到这种情况时不必认为是浏览器的问题,大多数浏览器应该不会死皮赖脸地把二进制文件当作文本打开,一般都是服务器给什么浏览器就开什么.解决方法: &...  阅读全文 该骗子诈骗短信内容：“温馨提示，现已从您帐上支出1300元，，工行客服：021—60512737。 一、连接池概述
　数据库连接池概述：
　　数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。对数据库连接的管理能显著影响到整个
应用程序的伸缩性和健壮性，影响到程序的性能指标。数据库连接池正是针对这个问题提出来的。
　　数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而再不是重新建立一个；释放空闲时
间超过最大空闲时间的数据库连接来避免因为没有释放数据库连接而引起的数据库连接遗漏。这项技术能明显提高对数据库操作的性能。
　　数据库连接池在初始化时将创建一定数量的数据库连接放到连接池中，这些数据库连接的数量是由最小数据库连接数来设定的。无论这些
数据库连接是否被使用，连接池都将一直保证至少拥有这么多的连接数量。连接池的最大数据库连接数量限定了这个连接池能占有的最大连接
数，当应用程序向连接池请求的连接数超过最大连接数量时，这些请求将被加入到等待队列中。数据库连接池的最小连接数和最大连接数的设
置要考虑到下列几个因素：
　　1) 最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费；
　　2) 最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之
后的数据库操作。
　　3) 如果最小连接数与最大连接数相差太大，那么最先的连接请求将会获利，之后超过最小连接数量的连接请求等价于建立一个新的数据库
连接。不过，这些大于最小连接数的数据库连接在使用完不会马上被释放，它将被放到连接池中等待重复使用或是空闲超时后被释放。
目前常用的连接池有：C3P0、DBCP、Proxool
网上的评价是：
C3P0比较耗费资源，效率方面可能要低一点。
DBCP在实践中存在BUG，在某些种情会产生很多空连接不能释放，Hibernate3.0已经放弃了对其的支持。
Proxool的负面评价较少，现在比较推荐它，而且它还提供即时监控连接池状态的功能，便于发现连接泄漏的情况。
配置如下：
1、在spring配置文件中，一般在applicationContext.xml中
     <bean id="proxoolDataSource" class="org.logicalcobwebs.proxool.ProxoolDataSource">
            <property name="driver" value="${jdbc.connection.driverClassName}"/>
            <property name="driverUrl" value="${jdbc.connection.url}"/>
            <property name="user" value="${jdbc.connection.username}"/>
            <property name="password" value="${jdbc.connection.password}"/>
            <!-- 测试的SQL执行语句 -->
           <property name="houseKeepingTestSql" value="${proxool.houseKeepingTestSql}"/>
            <!-- 最少保持的空闲连接数 （默认2个） -->
             <property name="prototypeCount" value="${proxool.prototypeCount}"/>
            <!-- proxool自动侦察各个连接状态的时间间隔(毫秒),侦察到空闲的连接就马上回收,超时的销毁 默认30秒） -->
            <property name="houseKeepingSleepTime" value="${proxool.hourseKeepingSleepTime}"/>
            <!-- 最大活动时间(超过此时间线程将被kill,默认为5分钟) -->
             <property name="maximumActiveTime" value="${proxool.maximumActiveTime}"/>
            <!-- 连接最长时间(默认为4个小时) -->
            <property name="maximumConnectionLifetime" value="${proxool.maximumConnectionLifetime}"/>
            <!-- 最小连接数 （默认2个） -->
            <property name="minimumConnectionCount" value="${proxool.minimumConnectionCount}"/>
            <!-- 最大连接数 （默认5个） -->
            <property name="maximumConnectionCount" value="${proxool.maximumConnectionCount}"/>
            <!-- -->
            <property name="statistics" value="${proxool.statistics}"/>
            <!-- 别名 -->
             <property name="alias" value="${proxool.alias}"/>
            <!-- -->
            <property name="simultaneousBuildThrottle" value="${proxool.simultaneous-build-throttle}"/>
     </bean>
     然后注入到sessionFactory中
     <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
           <property name="dataSource" ref="proxoolDataSource"/>
     </bean>
 
Porxool 配置文件
--==--==--==--==--==<proxool.xml>==--==--==--==--==--==--==
<?xml version="1.0" encoding="UTF-8"?>
<proxool>
      <alias>WMS</alias>
      <driver-url>jdbc:postgresql://192.168.210.184:5432/wms</driver-url>
      <driver-class>org.postgresql.Driver</driver-class>
      <driver-properties>
             <property name="user" value="wms_user" />
             <property name="password" value="wms" />
      </driver-properties>
      <minimum-connection-count>2</minimum-connection-count>
      <maximum-connection-count>40</maximum-connection-count>
      <simultaneous-build-throttle>20</simultaneous-build-throttle>
      <prototype-count>2</prototype-count>
      <house-keeping-test-sql>select CURRENT_DATE</house-keeping-test-sql>
</proxool>
--==--==--==--==--==<proxool.xml>==--==--==--==--==--==--==
 
配置说明：
alias                                          -〉数据库连接别名（程序中需要使用的名称）
driver-url                                   -〉数据库驱动
driver-class                                -〉驱动程序类
driver-properties                        -〉联机数据库的用户和密码
minimum-connection-count          -〉最小连接数量，建议设置0以上，保证第一次连接时间
maximum-connection-count         -〉最大连接数量，如果超过最大连接数量则会抛出异常。连接数设置过多，服务器CPU和内存性能消耗很
大。
simultaneous-build-throttle          -〉同时最大连接数
prototype-count                          -〉一次产生连接的数量。
                                                 例：如果现在prototype-count设置为4个，但是现在已经有2个可以获得的连接，那么
将会试图再创建2个连接。
                                                  但不能超过最大连接数。
maximum-active-time                 -〉连接最大时间活动 默认5分钟
maximum-connection-lifetime      -〉连接最大生命时间 默认4小时 /**
*作者：张荣华(ahuaxuan)
*2007-8-15
*转载请注明出处及作者
*/

前两天在看Spring内置的拦截器的时候，发现了一个之前没有注意的类：org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor，好奇心促使我上网查了一下这个jamon。大概看了一下之后发现这个玩意还真挺好用的而且挺重要的，而且现在国内对它的介绍也很少，所以写了一篇文章和大家分享。

一，Jamon简介：
Jamon的全名是：Java Application Monitor。它是一个小巧的，免费的，高性能的，线程安全的性能监测工具。它可以用来测定系统的性能瓶颈，也可以用来监视用户和应用程序之间的交互情况。 Jamon主要是用来检测jee的应用程序。它最新的版本是2.1，可以用在1.4以上的jdk上。

二，将jamon导入到你的应用程序中去
首先下载jamon的开发包，见我的附件，同时你也可以去Sourceforge上自己下载。Sourceforge的下载地址为http://jamonapi.sourceforge.net。解压之后可以得到一个jar包和一个war包。jar包是自己会用到的，而war包是一个例子（不要小看这个例子，待会也要把它导入到项目中）。把war包之间丢到服务器上，访问：localhost:8080/jamon就可以看到这个例子了，这个例子是一个简单的性能监控系统。

接着把例子中的所有的包都导入到项目中，并把war包中的jsp和images还有css都考到项目中，比如新建一个目录叫monitor（它和WEB-INF是同级目录）。

三，正确配置自己的应用
我们在性能监测的时候最监测的就是页面的访问率和类中方法的访问率。所以在这一部分主要讲解一下如何监测自己的页面和类中方法的访问。

1， 检测自己的页面访问率
首先我们需要在web.xml中添加一个filter，这个filter就是用来判断哪些页面需要被监视的，如下所示：

<filter>
<filter-name>JAMonFilter</filter-name>
<filter-class>com.easywebwork.filter.EasyPageMonFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>JAMonFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

接下来我们看看这个filter的写法：

/**
* @author 张荣华（ahuaxuan）
*
* @since 2007-8-13
*/
public class PageMonFilter extends JAMonFilter{
private static final long serialVersionUID = 5746197114960908454L;
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
Monitor allPages = MonitorFactory.start(new MonKeyImp("org.easywebwork.allPages",getURI(request),"ms."));
//这里就是我们要监视的所有的页面的配置
Monitor monitor = MonitorFactory.start(getURI(request));
//这里就是我们要监视的某个页面的配置
try {
filterChain.doFilter(request, response);
} finally {
monitor.stop();
allPages.stop();
}
}
protected String getURI(ServletRequest request) {
if (request instanceof HttpServletRequest) {
return ((HttpServletRequest) request).getRequestURI();
} 	else {
return "Not an HttpServletRequest";
}
}
private FilterConfig filterConfig = null;
}}

这个类看上去很简单，其实也挺简单的，就是得到uri，然后把它注册到MonitorFactory类中。这样只要我们去访问刚才创建的monitor目录下的jsp就可以看到性能监测页面了。

2， ，接下来我们看看在使用spring的情况下如何监测一个bean的方法调用。Spring也提供了对Jamon的支持(spring支持的东西还真多啊)，也就是文章开头提出的那个拦截器，为了给我们的bean加上拦截器，我们在spring的applicationcontext配置文件中加入如下语句：

<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list>
<value>userService</value>
</list>
</property>
<property name="interceptorNames">
<list>
<value>jamonInterceptor</value>
</list>
</property>
</bean>
<bean id="jamonInterceptor" class="org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor">
</bean>

上面这个是典型的spring的aop的配置，如果对spring的aop配置不了解的可以去看一下spring中文文档，当然如果不想了解的话即使直接把这段配置拷到自己的项目中也是可以直接使用的。

还有一个步骤就是在你的log4j.properties中加入这句代码：

log4j.logger.org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor = TRACE

如果没有这一行，那么这个拦截器是不会把方法调用的信息向MonitorFactory注册的。

只需要这些步骤，userservice中的方法在调用的时候就可以被拦截，然后将其注册到MonitorFactory中去了。

所有的配置完成之后我们来看一下效果吧:
http://www.javaeye.com/topics/download/b2bac96e-6c18-4340-b7e0-f84c7bb6adca从这个图上我们可以看到，所有页面被访问的次数，UserService中的getAllUsers被调用的次数，最右边的是访问时间。这只是整个图的一部分，当然这个页面中也包括每一个页面被访问的次数和第一次访问的时间等等。下载附件运行，就可以看到所有的页面了。

三，总结
根据以上的步骤，我们就可以监测我们的程序了，应用程序中哪些页面被访问的多，哪些页面被访问的少，哪些方法被访问的多，哪些方法被访问的少，以及访问高峰期集中在什么时间等等，有了这些参数，我们更可以有针对性的对应用程序进行优化了，比如说某个页面访问比较频繁，我就可以用ehcache或oscache给这个页面做一个缓存。如果某个方法的访问比较频繁那就看看这个方法能否进一步优化，是需要异步，还是需要缓存，还是需要其他等等，总之有了jamon可以给我们带来更多的便捷，既可以让我们知道我们的客户的行为，也可以让我们知道我们开发的程序的“能力”。

其实本文提供的只是对页面和方法调用的监控，但是jamon可以提供更多功能，比如说sql语句的监控等等，这就需要我们共同去发掘了。

附件中包括了一个easywebwork的例子，我把jamon导入到这个例子工程中去，大家可以直接下载运行观看效果。Easywebwork是一个旨在减少webwork2.2.x系列的xml配置文件的项目，
如果对这个主题感兴趣请到
http://www.javaeye.com/topic/91614
http://www.javaeye.com/topic/93814
参加讨论。





之前有一篇文章讲到如何使用jamon来监控请求以及方法得调用(原文地址见：[url]http://www.javaeye.com/post/354575 [/url])，本文属于其姊妹篇，使用jamon监控系统的sql调用及其调用效率。

需求：
1我们知道在使用hibernate得时候，我们可以打开show sql选项，可以直接查看sql语句调用的情况，那么当我们使用其他持久技术的时候我们也需要这个功能怎么办呢，没有关系，jamon能够帮我们做到。

2 很多时候，不同的程序员会写出不同的性能的sql，有时候可能会不小心或者因为不知道而写出性能很差的sql，我自己曾经就发生过这种事情，在500w条数据的表里使用了一个limit来分页，到后面，执行一条sql都需要几分钟，诸如此类的时候可能大家都有碰到过，如果能有监控sql性能的工具嵌在应用里该多好，当然有jamon就可以帮我们做到。

对于jamon来说，每一个query的执行之后的统计结果都会被保存下来，这些概要统计都以MonProxy-SQL开头。这些统计中包括查询执行的时间，有比如平均时间，执行总时间，最小执行时间，最大执行时间，这些东西难道不是我们正想要的吗。

那么让我们开始吧，我们知道，这些query执行的统计应该是在connection中被统计的，也就是说我们要代理一般的connection，而connection又是由datasource产生的，所以我们可以代理datasource，说干就干。

一个datasource接口中关于connection的方法只有两个：

/**
* <p>Attempts to establish a connection with the data source that
* this <code>DataSource</code> object represents.
*
* @return  a connection to the data source
* @exception SQLException if a database access error occurs
*/
Connection getConnection() throws SQLException;
/**
* <p>Attempts to establish a connection with the data source that
* this <code>DataSource</code> object represents.
*
* @param username the database user on whose behalf the connection is
*  being made
* @param password the user's password
* @return  a connection to the data source
* @exception SQLException if a database access error occurs
* @since 1.4
*/
Connection getConnection(String username, String password)
throws SQLException;

也就是说我们只要override这两个方法即可。
根据这个思路我写了以下代码：

/**
* @author ahuaxuan(aaron zhang)
* @since 2008-2-25
* @version $Id$
*/
public class MonitorDataSource implements DataSource {
public DataSource realDataSource;
public void setRealDataSource(DataSource realDataSource) {
this.realDataSource = realDataSource;
}
public DataSource getRealDataSource() {
return realDataSource;
}
public Connection getConnection() throws SQLException {
//表示由jamon来代理realDataSource返回的Connection
return MonProxyFactory.monitor(realDataSource.getConnection());
}
public Connection getConnection(String username, String password)
throws SQLException {
//表示由jamon来代理realDataSource返回的Connection
return MonProxyFactory.monitor(realDataSource.getConnection(username,
password));
}
}

显然这个一个代理模式。接下来就是生成这个代理类,我是在spring中注册了这么一个类：

<bean id="writeMonitorDataSource" class="org.ahuaxuan.MonitorDataSource" destroy-method="close">
<property name="realDataSource" ref="writeDataSource"/>
</bean>

writeMonitorDataSource 所依赖的writeDataSource就是我们真正配置的datasource，比如：

<bean id="writeDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName">
<value>${jdbc.driverClassName}</value>
</property>
<property name="url">
<value>${jdbc.url}</value>
</property>
<property name="username">
<value>${jdbc.username}</value>
</property>
<property name="password">
<value>${jdbc.password}</value>
</property>
<property name="maxActive">
<value>${jdbc.maxActive}</value>
</property>
<property name="maxIdle">
<value>${jdbc.maxIdle}</value>
</property>
<property name="maxWait">
<value>${jdbc.maxWait}</value>
</property>
</bean>

好了，那么在使用datasource的时候，我们应该用哪个呢，当然是writeMonitorDataSource这个里，我们可以把它注入给jdbcTemplate，或者sessionfactory，或者其他需要用到datasource的地方。

到这里，就一切准备完毕了，我们可以看看我们sql语句的执行效率了(这个页面的地址为sql.jsp)：
见图1
当然要我们的应用能够显示这个页面，我们需要把jamon的一组页面拷到我们的应用中，这一组页面包含在我提供下载的包中，最新的jamon版本是2.7。

我们可以看到id为153的那条sql语句执行了78ms，我要去看看这条sql语句是不是有点什么问题或者是否有优化的可能性。

当然，刚才说到每一条sql语句都是有统计平均时间，最大最小执行时间等等，没错，在另外一个页面jamonadmin.jsp上就包含这些内容
见图2
      

上面的图片代表hits表示执行次数，avg表示sql执行的平均时间，后面的min和max表示sql执行的最小耗时和最大耗时。从这里我们能够更直观的看到我们每条sql语句执行的情况。很有用的一个功能。

而且在上面那两个页面上，我们还可以选择把sql执行的结果导出来，可以导成xml或excel格式。

总结：使用jamon来监控我们的sql语句我觉得很有使用意义，而且使用jamon对我们的应用来说完全是松耦合的，根本不需要更改我们的业务逻辑代码，完全是可插拔的，我们也可以开发时使用jamon，部署时拔掉jamon。有了它能够使一些程序员能够更多一点的关注自己所写的sql的效率，当然如果之前开发的时候没有使用jamon也没有关系，即使上线后也可以查看一下sql语句是否有问题，比如哪些sql语句执行得比较频繁，是否存在给其做缓存得可能性等等。总之使用jamon在应用程序中来监控我们得sql语句具有很强得实用意义，

再次总结：jamon，很好，很强大。
我在解析XML文件中出现如下错误:

org.xml.sax.SAXParseException: The reference to entity "Stars" must end with the  ';' delimiter.

经查实发现,xml文件里有&的字眼

把其中的"&"转义字符&amp; 代替,就OK了