那么，网址劫持是怎么回事呢？

302重定向和网址劫持有什么关系呢？这要从搜索引擎如何处理302转向说起。从定义来说，从网址A做一个302重定向到网址B时，主机服务器的隐含意思是网址A随时有可能改主意，重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下，当收到302重定向时，一般只要去抓取目标网址就可以了，也就是说网址B。实际上如果搜索引擎在遇到302转向时，百分之百的都抓取目标网址B的话，就不用担心网址URL劫持了。

问题就在于，有的时候搜索引擎，尤其是Google，并不能总是抓取目标网址。为什么呢？比如说，有的时候A网址很短，但是它做了一个302重定向到B网址，而B网址是一个很长的乱七八糟的URL网址，甚至还有可能包含一些问号之类的参数。很自然的，A网址更加用户友好，而B网址既难看，又不用户友好。这时Google很有可能会仍然显示网址A。

由于搜索引擎排名算法只是程序而不是人，在遇到302重定向的时候，并不能像人一样的去准确判定哪一个网址更适当，这就造成了网址URL劫持的可能性。也就是说，一个不道德的人在他自己的网址A做一个302重定向到你的网址B，出于某种原因， Google搜索结果所显示的仍然是网址A，但是所用的网页内容却是你的网址B上的内容，这种情况就叫做网址URL劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

当网页A用301重定向转到网页B时，搜索引擎可以肯定网页A永久的改变位置，或者说实际上不存在了，搜索引擎就会把网页B当作唯一有效目标。301的好处是:

（1）没有网址规范化问题。
（2）网页A的PR网页级别会传到网页B，这对SEO非常重要！

在实际操作过程中，我和同事对一个站点（www.woshuone.com）做了实验。结果发现不管是使用301还是302，很容易被Google “K掉”，取消跳转之后过一周左右的时间就又恢复了。看来搜索引擎蜘蛛现在对页面跳转还是比较反感，认为作弊的可能性大，宁可错杀一百也不放过一人！

作者：Mark Levison 译者：赖勤毅 发布于 2010年11月5日

现在已经到第十次迭代开发周期了，你的项目开发速度开始变慢。在之前的几个迭代周期中，团队没有像以前那样完成很多的“故事场景”（stories）。此外，最近在新的故事场景和回溯中却发现更多缺陷(bug)。项目经理知道，团队成员没有变，他们也花同样的时间工作。但是，客户会发问：“发生什么事情了？这个团队还在努力工作吗？”

很多敏捷团队的产品改进率为150-500%，可是你们的项目看起来却貌似只有20-40%左右的改进率。这到底是怎么回事呢？在此我们找不到什么大问题；相反，只是有无数的小问题。有时，这些只是一些为了方便而使用的捷径（开发人员没有时间去清理这些修改），有时开发人员仅仅是不熟悉这中语言。还有一些问题就是，代码跟灌木丛一样凌乱，需要大幅度的修整。所有这些都属于“技术债务”。

什么是“技术债务”？

它就是“那些内在的事物，现在你不去解决，遗留下来（不干完），它就会阻碍未来开发”[Ward Cunningham]。 表面上，应用程序看起来质量很高且状况良好，但是这些问题却隐藏在下面。 QA（质量保证部门）甚至可能告诉你说，这个应用程序真是不错，几乎找不到缺陷，但是其中仍然存在“技术债务”，如果我们没有很好地管理并设法降低这些“技术债务”，那么，程序编写和维护的代价最终将会超过它对客户的价值。

技术债务就像信用卡一样，会有很高的利息率，就如同给团队留下了大量的帐务开销。这种情况下，开销将会体现在时间花费和解决问题所需的努力上面。开发团队拖延债务的时间越长，所积累的利息就越多（会额外增加很多工作），付出的成本也就越高。

另外，这还增加了实际的财务支出：开发团队处理技术债务所花费的时间，可以用在对团队有价值的其它工作上。同时，这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且，理解代码所损失的时间还可以用来做其它更有价值的事情呢。

我们为何要累积技术债务呢？

项目编码初期，不整理代码，不写单元测试，也不做测试驱动开发，整个团队粗制滥造出更多的“故事场景”。 这些问题通常都不会马上暴露出来，而循规蹈矩地编写代码往往需要更多的时间，特别是在早期阶段。

技术债务来自哪里？

• 没有经验的开发人员 —— 有些项目里面，编写Java/C#/Ruby的开发人员没有接受过培训，或者没有面向对象的观念。结果呢，他们会一直编写适用于他们曾经习惯的编程语言——像Visual Basic等——的代码。
• 项目工期的压力 —— 那些来自于经理或客户的显性压力和其它一些潜在的压力。“我们承诺在以后迭代（发布）的故事场景中做到这些”。开发团队会发现他们不会交付这些承诺的发行版本（迭代版本），而是采取便捷的手段。“我们不得不把事情做完；我们无法承担修整代码所耗费的时间。如果这不是新特性/缺陷，那么就不用去做”。 不幸的是，这些观点还会得到管理人员的支持，特别是在管理层没有意识到这些成本的时候。
• 凌乱而难读的代码。当一个方法或类中存在一些难读的代码，下一个开发人员继续这些工作的时候，就觉得他也没有必要迫使自己编写清晰的代码。所以，每次有人接手这些代码的时候，一小段脏乱的代码将会变成一大堆乱七八糟的代码。
• 专业领域的代码 —— 往往有这样的观念：这些代码看起来就是很差劲，但是这不属于我的领域，所以我不能或不会改变它们。另外，对于修改专业领域的代码，开发人员也会觉得力不从心。
• 过度复杂 —— 开发人员经常趋向于在需求之前设计解决方案。而且，很多情况下他们的代码没有找到正确的方向，还会写一些没有用处的代码。或者，这些代码没有真正地符合需求，因为代码在问题还没有完全明白的时候就已经写完了。还有另外一种情况，过度设计花费了额外的时间，产生的代码不是不能使用就是不符合项目的需求。
• 糟糕的设计 —— 有些解决方案只是设计不佳。但在设计不好的代码上面继续扩展，而不去解决这个问题，会使问题更加恶化。

解决问题

这个问题的并不是一下子可以解决的，解决方案需要通过几个迭代周期。并且，你需要耐心，并要从多个角度寻找解决途径。

解决方案中的要点

1. 让开发人员接受语言方面的基本培训并教授他们面向对象的原理，从而把他们的理解力提升至入门阶段。要想既成功又有效的话，这需要花几个礼拜的时间培训，还需要有精通这方面的人员来跟进和支持这一系列培训。
2. 告诉开发人员和管理人员，当前的这些问题都是需要花费企业资金的。这点尤其重要，因为它会使解决这些问题的意义更加明确。你要清楚地告诉他们，管理人员会重视这些问题，并且已经开始着手偿还这些技术债务了。不断支持这些工作使之成为常规的原则之一，这样整个团队就会信任这个准则。
3. 提供一些培训，包括代码的坏味道，重构，单元测试和测试驱动开发等。还可以结合课堂会议，基于网络的材料和书籍来进行培训。
4. 在工作的时候，给他们一些空余时间去研究和练习他们的技能（一个礼拜两个小时应该是达成这个目标的最小的时间量）。练习的代码应该被丢弃，这样，他们就能无拘无束地尝试和试验一些事情，不管怎么样，他们不用在基础代码库上面进行练习。花点时间练习和研究应该是最有用的建议了。假如没有为他们提供空闲的时间，就压根不会发现真正合理的敏捷开发方式。这种组织方式也被称为“道场”-Dojo（更加详细的资料可以参考 TDD Randori Session 和 TDD Randori Workshop）。
5. 使用工具（静态分析，单元测试，持续集成，自动化可接受性测试）来帮助团队发现、减少和衡量他们的技术债务量。应该在团队层面利用这些度量数据，而不能分享给管理人员。团队成员需要知道，他们并不会因为对这些技术债务的度量而接受奖励或者遭受惩罚。如果我们把这些度量数据报告给管理层，并由管理层来追踪的话，开发人员很快会找到一些窍门来规避它们，这样就失去了本来应有的价值了。
6. 当人们完成了他们的培训或者在技术上取得了少许提升时，应该得到奖励。奖励可以是给予一次认可的表彰或者是一些小小的礼物，但不要直接给予现金奖励。
7. 每两个礼拜进行一次午餐聚会和一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论。提供午餐可以提高参会人数。另外比较重要的是需要管理人员每次都来出席，这样就很清楚的表明他们也一直支持大家提高技术。
8. 维护关于技术债务的备忘录 – 任何时候，如果开发人员发现一些无法立即应付的技术债务时，就需要填写一份技术债务登记卡。开发人员应该优先考虑这些技术债务，并花费10-15%的精力来偿还这些技术债务。大多数项目中，任何的一些小事都会使问题变得更加严重。

基于这样的立场，你会发现问题，也会拥有机会。你的问题是：项目的基础代码一直在积累技术债务，但是这些债务已经开始下降了。然而，现在跟客户申请用于处理这些问题的资金会跟处理这些问题一样困难。你的机遇是：提高了开发人员的技能；清楚地表达了管理层对这项工作的支持，还有，软件的代码质量会不断改善，软件缺陷的数目也会不断减少。同时这也会很好的提高团队的整体开发能力。

一、从数据的角度来看，数据包括：收集、存储、分析（挖掘）、展示、提取。兼顾目前的系统，收集、存储、挖掘、提取，这几个环节的系统需要加强。特别是收集和提取这块。

由于历史的原因，加之没有系统规划过，之前的数据收集来源比较零散，这样导致分析数据时需要从各个地方来同步数据。当业务多了之后，这些乱七八糟的来源就够让人头疼了。这次规划的一个重点就是，建立一套游戏数据收集系统。游戏分析涉及的数据（日志类）都从这个系统中获取，不再单独分析各自的业务数据。业务系统采用数据上报的方式，按照固定的格式来上报数据。例如：登录、注册、充值、消耗等等。

采用这套游戏数据收集系统，还有一个重要的原因。现在我们的游戏都是独立运营游戏（我们是甲方），那么我们就可以采用类似腾讯的办法，事先定义好数据规范，要求游戏方按照我们的格式上报相关数据给我们。这样我们的数据分析系统就可以做到非常通用。不管接多少游戏，分析和展示系统都统一。

数据提取，这里主要是指临时数据。这是我们这边的一个顽疾。临时数据其实包括两个部分：数据来源和数据分析。一个常见的需求就是：分析一堆帐号（数据来源）的后续行为（数据分析）。因为临时数据的业务规则复杂，并且数据来源千奇百怪，之前采用过全手工、全自动的方式来实现，但是都失败了。现在想到的一个解决方案就是，基于游戏数据收集系统之上，再开发一个临时数据分析系统。

游戏数据收集系统统一了数据的来源和格式，方便存储和提取原始数据。这基本解决了数据来源的问题。临时数据分析系统，可以事先实现常见的分析逻辑（例如：登录、留存、保有、付费人数、付费金额、消耗等等），然后采用过滤器模式或包装器模式来实现。这其实是一个半自动化的方案。系统的用户是开发人员和产品人员。开发完这套系统应该可以省掉60%以上的临时数据任务。

另外，只要数据都是来自这套游戏数据收集系统，存储、分析，包括挖掘都会简单很多。存储都会在HDFS上，分析基本都使用Hive，挖掘用Mahout。

游戏数据挖掘是需要单独发展的一块业务，特别是现在专注独立运营之后。目前这块我们还需要更多的时间来积累经验。

二、从服务的角度来看，服务包括：服务框架、服务管理、服务监控。

服务也是一个大范畴。服务化框架、页面登录服务器、GM接口，这些都属于服务相关的内容。兼顾目前的系统，这些内容都已经基本实现，这次只是做比较大的版本改进。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

1、线上应用故障排查之一：高CPU占用

2、线上应用故障排查之二：高内存占用

3、线上应用故障排查之三：高I/O占用，包括磁盘I/O、网络I/O、数据库I/O等。

4、线上应用故障排查之四：程序僵死

敬请期待！

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

搞Java开发的，经常会碰到下面两种异常：

1、java.lang.OutOfMemoryError: PermGen space

2、java.lang.OutOfMemoryError: Java heap space

要详细解释这两种异常，需要简单重提下Java内存模型。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

Java内存模型是描述Java程序中各变量（实例域、静态域和数组元素）之间的关系，以及在实际计算机系统中将变量存储到内存和从内存取出变量这样的低层细节。

在Java虚拟机中，内存分为三个代：新生代（New）、老生代（Old）、永久代（Perm）。

（1）新生代New：新建的对象都存放这里

（2）老生代Old：存放从新生代New中迁移过来的生命周期较久的对象。新生代New和老生代Old共同组成了堆内存。

（3）永久代Perm：是非堆内存的组成部分。主要存放加载的Class类级对象如class本身，method，field等等。

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：

（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。

一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。

从代码的角度，软件开发人员主要关注java.lang.OutOfMemoryError: Java heap space异常，减少不必要的对象创建，同时避免内存泄漏。

现在以一个实际的例子分析内存占用的故障排查。

通过top命令，发现PID为9004的Java进程一直占用比较高的内存不释放（24.7%），出现高内存占用的故障。

想起上一篇线上应用故障排查之一：高CPU占用介绍的PS命令，能否找到具体是哪个的线程呢？

ps -mp 9004 -o THREAD,tid,time,rss,size,%mem

遗憾的是，发现PS命令可以查到具体进程的CPU占用情况，但是不能查到一个进程下具体线程的内存占用情况。

只好寻求其他方法了，幸好Java提供了一个很好的内存监控工具：jmap命令

jmap命令有下面几种常用的用法：

•jmap [pid]

•jmap -histo:live [pid] >a.log

•jmap -dump:live,format=b,file=xxx.xxx [pid]

用得最多是后面两个。其中，jmap -histo:live [pid] 可以查看当前Java进程创建的活跃对象数目和占用内存大小。

jmap -dump:live,format=b,file=xxx.xxx [pid] 则可以将当前Java进程的内存占用情况导出来，方便用专门的内存分析工具（例如：MAT）来分析。

这个命令对于分析是否有内存泄漏很有帮助。具体怎么使用可以查看本博的另一篇文章：利用Eclipse Memory Analyzer Tool（MAT）分析内存泄漏

这里详细介绍下jmap -histo:live [pid] 命令：

从上图可以看出，int数组、constMethodKlass、methodKlass、constantPoolKlass都占用了大量的内存。

特别是占用了大量内存的int数组，需要仔细检查相关代码。

最后，总结下排查内存故障的方法和技巧有哪些：

1、top命令：Linux命令。可以查看实时的内存使用情况。  

2、jmap -histo:live [pid]，然后分析具体的对象数目和占用内存大小，从而定位代码。

3、jmap -dump:live,format=b,file=xxx.xxx [pid]，然后利用MAT工具分析是否存在内存泄漏等等。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

以我们最近出现的一个实际故障为例，介绍怎么定位和解决这类问题。

根据top命令，发现PID为28555的Java进程占用CPU高达200%，出现故障。

通过ps aux | grep PID命令，可以进一步确定是tomcat进程出现了问题。但是，怎么定位到具体线程或者代码呢？

首先显示线程列表:

ps -mp pid -o THREAD,tid,time

找到了耗时最高的线程28802，占用CPU时间快两个小时了！

其次将需要的线程ID转换为16进制格式：

printf "%x\n" tid

最后打印线程的堆栈信息：

jstack pid |grep tid -A 30

找到出现问题的代码了！

现在来分析下具体的代码：ShortSocketIO.readBytes(ShortSocketIO.java:106)

ShortSocketIO是应用封装的一个用短连接Socket通信的工具类。readBytes函数的代码如下：

public byte[] readBytes(int length) throws IOException {

    if ((this.socket == null) || (!this.socket.isConnected())) {

        throw new IOException("++++ attempting to read from closed socket");

    }

    byte[] result = null;

    ByteArrayOutputStream bos = new ByteArrayOutputStream();

    if (this.recIndex >= length) {

           bos.write(this.recBuf, 0, length);

           byte[] newBuf = new byte[this.recBufSize];

           if (this.recIndex > length) {

               System.arraycopy(this.recBuf, length, newBuf, 0, this.recIndex - length);

           }

           this.recBuf = newBuf;

           this.recIndex -= length;

    } else {

           int totalread = length;

           if (this.recIndex > 0) {

                totalread -= this.recIndex;

                bos.write(this.recBuf, 0, this.recIndex);

                this.recBuf = new byte[this.recBufSize];

                this.recIndex = 0;

    }

    int readCount = 0;

    while (totalread > 0) {

         if ((readCount = this.in.read(this.recBuf)) > 0) {

                if (totalread > readCount) {

                      bos.write(this.recBuf, 0, readCount);

                      this.recBuf = new byte[this.recBufSize];

                      this.recIndex = 0;

               } else {

                     bos.write(this.recBuf, 0, totalread);

                     byte[] newBuf = new byte[this.recBufSize];

                     System.arraycopy(this.recBuf, totalread, newBuf, 0, readCount - totalread);

                     this.recBuf = newBuf;

                     this.recIndex = (readCount - totalread);

             }

             totalread -= readCount;

        }

   }

}

问题就出在标红的代码部分。如果this.in.read()返回的数据小于等于0时，循环就一直进行下去了。而这种情况在网络拥塞的时候是可能发生的。

至于具体怎么修改就看业务逻辑应该怎么对待这种特殊情况了。

最后，总结下排查CPU故障的方法和技巧有哪些：

1、top命令：Linux命令。可以查看实时的CPU使用情况。也可以查看最近一段时间的CPU使用情况。

2、PS命令：Linux命令。强大的进程状态监控命令。可以查看进程以及进程中线程的当前CPU使用情况。属于当前状态的采样数据。

3、jstack：Java提供的命令。可以查看某个进程的当前线程栈运行情况。根据这个命令的输出可以定位某个进程的所有线程的当前运行状态、运行代码，以及是否死锁等等。

4、pstack：Linux命令。可以查看某个进程的当前线程栈运行情况。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

根据经验，应该是程序有死锁情况，于是在线上运行“jstack –F <pid>”命令，想把线程堆栈dump下来。

但是，发现这个命令老是报下面的错误：

Thread 27316: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

线上环境是：

Linux 2.6.18-194.el5 x86_64 x86_64 x86_64 GNU/Linux

java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

经过分析发现，这是JDK6u23之前版本的一个Bug，将JDK升级到最新版本（1.6.0_31）就可以解决问题了。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

（1）客户端发送一个请求A（长连接），在服务器端的业务层需要20秒以上才能接收到。

（2）客户端发送一个请求B（端连接），在服务器端的业务层可以迅速接收到。

从现象大致知道问题出在服务器端的网络接收层，大量通过长连接发送过来的请求都堵塞在网络层得不到处理（在网络层排队，还没到应用层）。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）

后来经过排查，发现是Netty中的OrderedMemoryAwareThreadPoolExecutor原因。相关代码如下：

MemoryAwareThreadPoolExecutor executor = new OrderedMemoryAwareThreadPoolExecutor(threadNums, maxChannelMemorySize,
                                                                                                        maxTotalMemorySize, keepAliveTime,
                                                                                                        TimeUnit.SECONDS);
ExecutionHandler executionHandler = new ExecutionHandler(executor);

public ChannelPipeline getPipeline() throws Exception
{
        ChannelPipeline pipeline = pipeline();
        pipeline.addLast("decoder", new AuthDecoder());
        pipeline.addLast("encoder", new AuthEncoder());
        pipeline.addLast("executor", executionHandler);
        pipeline.addLast("handler", new AuthServerHandler(commandFactory));
        return pipeline;
}

先介绍下背景知识，再来分析问题。

大家都知道，Netty是一个基于事件的NIO框架。在Netty中，一切网络动作都是通过事件来传播并处理的，例如：Channel读、Channel写等等。回忆下Netty的流处理模型：

Boss线程（一个服务器端口对于一个）---接收到客户端连接---生成Channel---交给Work线程池（多个Work线程）来处理。

具体的Work线程---读完已接收的数据到ChannelBuffer---触发ChannelPipeline中的ChannelHandler链来处理业务逻辑。

注意：执行ChannelHandler链的整个过程是同步的，如果业务逻辑的耗时较长，会将导致Work线程长时间被占用得不到释放，从而影响了整个服务器的并发处理能力。

所以，为了提高并发数，一般通过ExecutionHandler线程池来异步处理ChannelHandler链（worker线程在经过ExecutionHandler后就结束了，它会被ChannelFactory的worker线程池所回收）。在Netty中，只需要增加一行代码：

public ChannelPipeline getPipeline() {
         return Channels.pipeline(
                 new DatabaseGatewayProtocolEncoder(),
                 new DatabaseGatewayProtocolDecoder(),
                 executionHandler, // Must be shared
                 new DatabaseQueryingHandler());

}

例如：

ExecutionHandler executionHandler = new ExecutionHandler(
             new OrderedMemoryAwareThreadPoolExecutor(16, 1048576, 1048576))

对于ExecutionHandler需要的线程池模型，Netty提供了两种可选：

1） MemoryAwareThreadPoolExecutor 通过对线程池内存的使用控制，可控制Executor中待处理任务的上限（超过上限时，后续进来的任务将被阻塞），并可控制单个Channel待处理任务的上限，防止内存溢出错误；

2） OrderedMemoryAwareThreadPoolExecutor 是 MemoryAwareThreadPoolExecutor 的子类。除了MemoryAwareThreadPoolExecutor 的功能之外，它还可以保证同一Channel中处理的事件流的顺序性，这主要是控制事件在异步处理模式下可能出现的错误的事件顺序，但它并不保证同一Channel中的事件都在一个线程中执行（通常也没必要）。

例如：

Thread X: --- Channel A (Event A1) --.   .-- Channel B (Event B2) --- Channel B (Event B3) --->
                                      \ /
                                       X
                                      / \
Thread Y: --- Channel B (Event B1) --'   '-- Channel A (Event A2) --- Channel A (Event A3) --->

上图表达的意思有几个：

（1）对整个线程池而言，处理同一个Channel的事件，必须是按照顺序来处理的。例如，必须先处理完Channel A (Event A1) ，再处理Channel A (Event A2)、Channel A (Event A3)

（2）同一个Channel的多个事件，会分布到线程池的多个线程中去处理。

（3）不同Channel的事件可以同时处理（分担到多个线程），互不影响。  

OrderedMemoryAwareThreadPoolExecutor 的这种事件处理有序性是有意义的，因为通常情况下，请求发送端希望服务器能够按照顺序处理自己的请求，特别是需要多次握手的应用层协议。例如：XMPP协议。

现在回到具体业务上来，我们这里的认证服务也使用了OrderedMemoryAwareThreadPoolExecutor。认证服务的其中一个环节是使用长连接，不断处理来自另外一个服务器的认证请求。通信的数据包都很小，一般都是200个字节以内。一般情况下，处理这个过程很快，所以没有什么问题。但是，由于认证服务需要调用第三方的接口，如果第三方接口出现延迟，将导致这个过程变慢。一旦一个事件处理不完，由于要保持事件处理的有序性，其他事件就全部堵塞了！而短连接之所以没有问题，是因为短连接一个Channel就一个请求数据包，处理完Channel就关闭了，根本不存在顺序的问题，所以在业务层可以迅速收到请求，只是由于同样的原因（第三方接口），处理时间会比较长。

其实，认证过程都是独立的请求数据包（单个帐号），每个请求数据包之间是没有任何关系的，保持这样的顺序没有意义！

最后的改进措施：

1、去掉OrderedMemoryAwareThreadPoolExecutor，改用MemoryAwareThreadPoolExecutor。

2、减少调用第三方接口的超时时间，让处理线程尽早回归线程池。

（友情提示：本博文章欢迎转载，但请注明出处：hankchen，http://www.blogjava.net/hankchen）