1.网速测试

安装iperf

yum install epel-release 从epel源中安装 yum install -y  iperf 

带宽检测

iperf -s 开启服务端  iperf -c ip 

丢包问题

tcpdump进行抓包  tcpdump -i eth0 -s 3000 port 8080 -w /home/tomcat.pcap  对于抓包文件采用wireshark进行分析  丢包(TCP DUP ACK) 重传(retransmission)，超时重传， 

2.cdn性能测试

cdn 缓存，回源问题    304请求，浏览器是否使用本地缓存。比较last_modified 和if_modified_since  通过实践戳来判断，浏览器缓存和cdn缓存 

3.DNS基础

路由解析

泛域名解析

4.分布式服务链路追踪

http入口产生一个traceId  分发到rpc调用，cache，db，jms调用链路中  google的著名论文dapper和zipkin  日志聚合，绑定链路日志和业务日志  采样采集，慢请求，异常服务。  日志量大。日志异步写入，环状数组，日志组件自研  共享信息放在ThreadLocal中。比如traceId 

5.网卡性能问题定位

tsar -l  -i 1 --traffic 查看网卡的进出流量 

6.CPU性能问题定位

tsar -l  -i 1 --cpu  软件问题定位，perf 采样所有进程数据  perf record -F 99 -a -g -- sleep 30  java进程的函数map：java -cp attach-main.jar:$JAVA_HOME/lib/tools.jar net.virtualvoid.perf.AttachOnce PID  输出函数和地址的map  输出火焰图 perf script | stackcollapse-perf.pl | flamegraph.pl --color=java --hash > flamegraph.svg 

7.内存性能问题定位

-堆内内存问题，

采用jmap dump内存，采用离线工具分析  jprofile、mat 

-堆外内存问题

a.google-perftools

yum install -y google-perftools graphviz  export LD_PRELOAD=/usr/lib64/libtcmalloc.so.4  export HEAPPROFILE=/home/testGperf.prof  执行程序，结束程序，生成prof  分析prof  生成svg, pdf,text pprof --svg $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.svg  pprof --pdf $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.pdf  pprof --text $JAVA_HOME/bin/java testGperf.prof.0001.heap > test.txt 

b.jemalloc定位（优势，适合长时间trace）

sudo apt-get install graphviz 编译安装 ./configure –enable-prof –enable-stats –enable-debug –enable-fill make make install

运行配置 export MALLOC_CONF=”prof:true,prof_gdump:true,prof_prefix:/home/jedump/jez,lg_prof_interval:30,lg_prof_sample:17”

export LD_PRELOAD=/usr/local/lib/libjemalloc.so.2 运行 java -jar target/spring-boot-jemalloc-example-0.0.1-SNAPSHOT.jar

jeprof –show_bytes –svg jez.*.heap > app-profiling.svg

注明：如果在docker容器中，推荐用pprof，jemalloc只显示函数地址，不显示函数名

8.机器资源配额问题

/etc/security/limits.conf

• soft nofile 65536
• hard nofile 65536

控制该用户文件句柄数

9.磁盘性能问题定位

tsar -l -i 1 –io

本文将深入浅出地讲解 JIT 编译器在 JVM 中的运作原理，使读者能够更好的理解 Java 底层机制并且为读者在 Java 性能优化领域打开更广的视野。

JIT 简介

JIT 是 just in time 的缩写, 也就是即时编译编译器。使用即时编译器技术，能够加速 Java 程序的执行速度。下面，就对该编译器技术做个简单的讲解。

首先，我们大家都知道，通常通过 javac 将程序源代码编译，转换成 java 字节码，JVM 通过解释字节码将其翻译成对应的机器指令，逐条读入，逐条解释翻译。很显然，经过解释执行，其执行速度必然会比可执行的二进制字节码程序慢很多。为了提高执行速度，引入了 JIT 技术。

在运行时 JIT 会把翻译过的机器码保存起来，以备下次使用，因此从理论上来说，采用该 JIT 技术可以接近以前纯编译技术。下面我们看看，JIT 的工作过程。

JIT 编译过程

当 JIT 编译启用时（默认是启用的），JVM 读入.class 文件解释后，将其发给 JIT 编译器。JIT 编译器将字节码编译成本机机器代码，下图展示了该过程。

图 1. JIT 工作原理图

回页首

Hot Spot 编译

当 JVM 执行代码时，它并不立即开始编译代码。这主要有两个原因：

首先，如果这段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。

当然，如果一段代码频繁的调用方法，或是一个循环，也就是这段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。其实说简单点，就是 JIT 在起作用，我们知道，对于 Java 代码，刚开始都是被编译器编译成字节码文件，然后字节码文件会被交由 JVM 解释执行，所以可以说 Java 本身是一种半编译半解释执行的语言。Hot Spot VM 采用了 JIT compile 技术，将运行频率很高的字节码直接编译为机器指令执行以提高性能，所以当字节码被 JIT 编译为机器码的时候，要说它是编译执行的也可以。也就是说，运行时，部分代码可能由 JIT 翻译为目标机器指令（以 method 为翻译单位，还会保存起来，第二次执行就不用翻译了）直接执行。

第二个原因是最优化，当 JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么 JVM 在编译代码的时候就做出相应的优化。

我们将在后面讲解这些优化策略，这里，先举一个简单的例子：我们知道 equals() 这个方法存在于每一个 Java Object 中（因为是从 Object class 继承而来）而且经常被覆写。当解释器遇到 b = obj1.equals(obj2) 这样一句代码，它则会查询 obj1 的类型从而得知到底运行哪一个 equals() 方法。而这个动态查询的过程从某种程度上说是很耗时的。

寄存器和主存

其中一个最重要的优化策略是编译器可以决定何时从主存取值，何时向寄存器存值。考虑下面这段代码：

清单 1. 主存 or 寄存器测试代码

public class RegisterTest {  private int sum;   public void calculateSum(int n) {  for (int i = 0; i < n; ++i) {  sum += i;  }  } }

在某些时刻，sum 变量居于主存之中，但是从主存中检索值是开销很大的操作，需要多次循环才可以完成操作。正如上面的例子，如果循环的每一次都是从主存取值，性能是非常低的。相反，编译器加载一个寄存器给 sum 并赋予其初始值，利用寄存器里的值来执行循环，并将最终的结果从寄存器返回给主存。这样的优化策略则是非常高效的。但是线程的同步对于这种操作来说是至关重要的，因为一个线程无法得知另一个线程所使用的寄存器里变量的值，线程同步可以很好的解决这一问题，有关于线程同步的知识，我们将在后续文章中进行讲解。

寄存器的使用是编译器的一个非常普遍的优化。

回到之前的例子，JVM 注意到每次运行代码时，obj1 都是 java.lang.String 这种类型，那么 JVM 生成的被编译后的代码则是直接调用 String.equals() 方法。这样代码的执行将变得非常快，因为不仅它是被编译过的，而且它会跳过查找该调用哪个方法的步骤。

当然过程并不是上面所述这样简单，如果下次执行代码时，obj1 不再是 String 类型了，JVM 将不得不再生成新的字节码。尽管如此，之后执行的过程中，还是会变的更快，因为同样会跳过查找该调用哪个方法的步骤。这种优化只会在代码被运行和观察一段时间之后发生。这也就是为什么 JIT 编译器不会理解编译代码而是选择等待然后再去编译某些代码片段的第二个原因。

回页首

初级调优：客户模式或服务器模式

JIT 编译器在运行程序时有两种编译模式可以选择，并且其会在运行时决定使用哪一种以达到最优性能。这两种编译模式的命名源自于命令行参数（eg: -client 或者 -server）。JVM Server 模式与 client 模式启动，最主要的差别在于：-server 模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。原因是：当虚拟机运行在-client 模式的时候，使用的是一个代号为 C1 的轻量级编译器，而-server 模式启动的虚拟机采用相对重量级代号为 C2 的编译器。C2 比 C1 编译器编译的相对彻底，服务起来之后，性能更高。

通过 java -version 命令行可以直接查看当前系统使用的是 client 还是 server 模式。例如：

图 2. 查看编译模式

回页首

中级编译器调优

大多数情况下，优化编译器其实只是选择合适的 JVM 以及为目标主机选择合适的编译器（-cient，-server 或是-xx:+TieredCompilation）。多层编译经常是长时运行应用程序的最佳选择，短暂应用程序则选择毫秒级性能的 client 编译器。

优化代码缓存

当 JVM 编译代码时，它会将汇编指令集保存在代码缓存。代码缓存具有固定的大小，并且一旦它被填满，JVM 则不能再编译更多的代码。

我们可以很容易地看到如果代码缓存很小所具有的潜在问题。有些热点代码将会被编译，而其他的则不会被编译，这个应用程序将会以运行大量的解释代码来结束。

这是当使用 client 编译器模式或分层编译时很频繁的一个问题。当使用普通 server 编译器模式时，编译合格的类的数量将被填入代码缓存，通常只有少量的类会被编译。但是当使用 client 编译器模式时，编译合格的类的数量将会高很多。

在 Java 7 版本，分层编译默认的代码缓存大小经常是不够的，需要经常提高代码缓存大小。大型项目若使用 client 编译器模式，则也需要提高代码缓存大小。

现在并没有一个好的机制可以确定一个特定的应用到底需要多大的代码缓存。因此，当需要提高代码缓存时，这将是一种凑巧的操作，一个通常的做法是将代码缓存变成默认大小的两倍或四倍。

可以通过 –XX:ReservedCodeCacheSize=Nflag（N 就是之前提到的默认大小）来最大化代码缓存大小。代码缓存的管理类似于 JVM 中的内存管理：有一个初始大小（用-XX:InitialCodeCacheSize=N 来声明）。代码缓存的大小从初始大小开始，随着缓存被填满而逐渐扩大。代码缓存的初始大小是基于芯片架构（例如 Intel 系列机器，client 编译器模式下代码缓存大小起始于 160KB，server 编译器模式下代码缓存大小则起始于 2496KB）以及使用的编译器的。重定义代码缓存的大小并不会真正影响性能，所以设置 ReservedCodeCacheSize 的大小一般是必要的。

再者，如果 JVM 是 32 位的，那么运行过程大小不能超过 4GB。这包括了 Java 堆，JVM 自身所有的代码空间（包括其本身的库和线程栈），应用程序分配的任何的本地内存，当然还有代码缓存。

所以说代码缓存并不是无限的，很多时候需要为大型应用程序来调优（或者甚至是使用分层编译的中型应用程序）。比如 64 位机器，为代码缓存设置一个很大的值并不会对应用程序本身造成影响，应用程序并不会内存溢出，这些额外的内存预定一般都是被操作系统所接受的。

编译阈值

在 JVM 中，编译是基于两个计数器的：一个是方法被调用的次数，另一个是方法中循环被回弹执行的次数。回弹可以有效的被认为是循环被执行完成的次数，不仅因为它是循环的结尾，也可能是因为它执行到了一个分支语句，例如 continue。

当 JVM 执行一个 Java 方法，它会检查这两个计数器的总和以决定这个方法是否有资格被编译。如果有，则这个方法将排队等待编译。这种编译形式并没有一个官方的名字，但是一般被叫做标准编译。

但是如果方法里有一个很长的循环或者是一个永远都不会退出并提供了所有逻辑的程序会怎么样呢？这种情况下，JVM 需要编译循环而并不等待方法被调用。所以每执行完一次循环，分支计数器都会自增和自检。如果分支计数器计数超出其自身阈值，那么这个循环（并不是整个方法）将具有被编译资格。

这种编译叫做栈上替换（OSR），因为即使循环被编译了，这也是不够的：JVM 必须有能力当循环正在运行时，开始执行此循环已被编译的版本。换句话说，当循环的代码被编译完成，若 JVM 替换了代码（前栈），那么循环的下个迭代执行最新的被编译版本则会更加快。

标准编译是被-XX:CompileThreshold=Nflag 的值所触发。Client 编译器模式下，N 默认的值 1500，而 Server 编译器模式下，N 默认的值则是 10000。改变 CompileThreshold 标志的值将会使编译器相对正常情况下提前（或推迟）编译代码。在性能领域，改变 CompileThreshold 标志是很被推荐且流行的方法。事实上，您可能知道 Java 基准经常使用此标志（比如：对于很多 server 编译器来说，经常在经过 8000 次迭代后改变次标志）。

我们已经知道 client 编译器和 server 编译器在最终的性能上有很大的差别，很大程度上是因为编译器在编译一个特定的方法时，对于两种编译器可用的信息并不一样。降低编译阈值，尤其是对于 server 编译器，承担着不能使应用程序运行达到最佳性能的风险，但是经过测试应用程序我们也发现，将阈值从 8000 变成 10000，其实有着非常小的区别和影响。

检查编译过程

中级优化的最后一点其实并不是优化本身，而是它们并不能提高应用程序的性能。它们是 JVM（以及其他工具）的各个标志，并可以给出编译工作的可见性。它们中最重要的就是--XX:+PrintCompilation（默认状态下是 false）。

如果 PrintCompilation 被启用，每次一个方法（或循环）被编译，JVM 都会打印出刚刚编译过的相关信息。不同的 Java 版本输出形式不一样，我们这里所说的是基于 Java 7 版本的。

编译日志中大部分的行信息都是下面的形式：

清单 2. 日志形式

timestamp compilation_id attributes (tiered_level) method_name size depot

这里 timestamp 是编译完成时的时间戳，compilation_id 是一个内部的任务 ID，且通常情况下这个数字是单调递增的，但有时候对于 server 编译器（或任何增加编译阈值的时候），您可能会看到失序的编译 ID。这表明编译线程之间有些快有些慢，但请不要随意推断认为是某个编译器任务莫名其妙的非常慢。

用 jstat 命令检查编译

要想看到编译日志，则需要程序以-XX:+PrintCompilation flag 启动。如果程序启动时没有 flag，您可以通过 jstat 命令得到有限的可见性信息。

Jstat 有两个选项可以提供编译器信息。其中，-compile 选项提供总共有多少方法被编译的总结信息（下面 6006 是要被检查的程序的进程 ID）：

清单 3 进程详情

% jstat -compiler 6006 CompiledFailedInvalid TimeFailedTypeFailedMethod 206 0 0 1.97 0

注意，这里也列出了编译失败的方法的个数信息，以及编译失败的最后一个方法的名称。

另一种选择，您可以使用-printcompilation 选项得到最后一个被编译的方法的编译信息。因为 jstat 命令有一个参数选项用来重复其操作，您可以观察每一次方法被编译的情况。举个例子：

Jstat 对 6006 号 ID 进程每 1000 毫秒执行一次： %jstat –printcompilation 6006 1000，具体的输出信息在此不再描述。

回页首

高级编译器调优

这一节我们将介绍编译工作剩下的细节，并且过程中我们会探讨一些额外的调优策略。调优的存在很大程度上帮助了 JVM 工程师诊断 JVM 自身的行为。如果您对编译器的工作原理很感兴趣，这一节您一定会喜欢。

编译线程

从前文中我们知道，当一个方法（或循环）拥有编译资格时，它就会排队并等待编译。这个队列是由一个或很多个后台线程组成。这也就是说编译是一个异步的过程。它允许程序在代码正在编译时被继续执行。如果一个方法被标准编译方式所编译，那么下一个方法调用则会执行已编译的方法。如果一个循环被栈上替换方式所编译，那么下一次循环迭代则会执行新编译的代码。

这些队列并不会严格的遵守先进先出原则：哪一个方法的调用计数器计数更高，哪一个就拥有优先权。所以即使当一个程序开始执行，并且有大量的代码需要编译，这个优先权顺序将帮助并保证最重要的代码被优先编译（这也是为什么编译 ID 在 PrintComilation 的输出结果中有时会失序的另一个原因）。

当使用 client 编译器时，JVM 启动一个编译线程，而 server 编译器有两个这样的线程。当分层编译生效时，JVM 会基于某些复杂方程式默认启动多个 client 和 server 线程，涉及双日志在目标平台上的 CPU 数量。如下图所示：

分层编译下 C1 和 C2 编译器线程默认数量：

图 3. C1 和 C2 编译器默认数量

编译器线程的数量可以通过-XX:CICompilerCount=N flag 进行调节设置。这个数量是 JVM 将要执行队列所用的线程总数。对于分层编译，三分之一的（至少一个）线程被用于执行 client 编译器队列，剩下的（也是至少一个）被用来执行 server 编译器队列。

在何时我们应该考虑调整这个值呢？如果一个程序被运行在单 CPU 机器上，那么只有一个编译线程会更好一些：因为对于某个线程来说，其对 CPU 的使用是有限的，并且在很多情况下越少的线程竞争资源会使其运行性能更高。然而，这个优势仅仅局限于初始预热阶段，之后，这些具有编译资格的方法并不会真的引起 CPU 争用。当一个股票批处理应用程序运行在单 CPU 机器上并且编译器线程被限制成只有一个，那么最初的计算过程将比一般情况下快 10%（因为它没有被其他线程进行 CPU 争用）。迭代运行的次数越多，最初的性能收益就相对越少，直到所有的热点方法被编译完性能收益也随之终止。

回页首

结束语

本文详细介绍了 JIT 编译器的工作原理。从优化的角度讲，最简单的选择就是使用 server 编译器的分层编译技术，这将解决大约 90%左右的与编译器直接相关的性能问题。最后，请保证代码缓存的大小设置的足够大，这样编译器将会提供最高的编译性能。

转载自点击打开链接

Hot Spot 编译

当 JVM 执行代码时，它并不立即开始编译代码。这主要有两个原因：

首先，如果这段代码本身在将来只会被执行一次，那么从本质上看，编译就是在浪费精力。因为将代码翻译成 java 字节码相对于编译这段代码并执行代码来说，要快很多。

当 然，如果一段代码频繁的调用方法，或是一个循环，也就是这段代码被多次执行，那么编译就非常值得了。因此，编译器具有的这种权衡能力会首先执行解释后的代 码，然后再去分辨哪些方法会被频繁调用来保证其本身的编译。其实说简单点，就是 JIT 在起作用，我们知道，对于 Java 代码，刚开始都是被编译器编译成字节码文件，然后字节码文件会被交由 JVM 解释执行，所以可以说 Java 本身是一种半编译半解释执行的语言。Hot Spot VM 采用了 JIT compile 技术，将运行频率很高的字节码直接编译为机器指令执行以提高性能，所以当字节码被 JIT 编译为机器码的时候，要说它是编译执行的也可以。也就是说，运行时，部分代码可能由 JIT 翻译为目标机器指令（以 method 为翻译单位，还会保存起来，第二次执行就不用翻译了）直接执行。

第二个原因是最优化，当 JVM 执行某一方法或遍历循环的次数越多，就会更加了解代码结构，那么 JVM 在编译代码的时候就做出相应的优化。

我 们将在后面讲解这些优化策略，这里，先举一个简单的例子：我们知道 equals() 这个方法存在于每一个 Java Object 中（因为是从 Object class 继承而来）而且经常被覆写。当解释器遇到 b = obj1.equals(obj2) 这样一句代码，它则会查询 obj1 的类型从而得知到底运行哪一个 equals() 方法。而这个动态查询的过程从某种程度上说是很耗时的。

在主流商用JVM（HotSpot、J9）中，Java程序一开始是通过解释器（Interpreter）进行解释执行的。当JVM发现某个方法或代码块运行特别频繁时，就会把这些代码认定为“热点代码（Hot Spot Code）”，然后JVM会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为：即时编译器（Just In Time Compiler，JIT）

JIT编译器是“动态编译器”的一种，相对的“静态编译器”则是指的比如：C/C++的编译器

JIT并不是JVM的必须部分，JVM规范并没有规定JIT必须存在，更没有限定和指导JIT。但是，JIT性能的好坏、代码优化程度的高低却是衡量一款JVM是否优秀的最关键指标之一，也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

2. 编译器与解释器

首先，不是所有JVM都采用编译器和解释器并存的架构，但主流商用虚拟机，都同时包含这两部分。

2.1 配合过程

1. 当程序需要迅速启动然后执行的时候，解释器可以首先发挥作用，编译器不运行从而省去编译时间，立即执行程序

2. 在程序运行后，随着时间的推移，编译器逐渐发挥作用，把越来越多的代码编译成本地代码之后，可以获得更高的执行效率

3. 当程序运行环境中内存资源限制较大（如部分嵌入式系统中），可以使用解释执行来节约内存；反之，则可以使用编译执行来提升效率。

4. 同时，解释器还可以作为编译器（C2才会激进优化）激进优化时的一个“逃生门”，让编译器根据概率选择一些大多数时候都能提升运行速度的优化手段，当激进优化假设不成立。如：加载了新类后，类型继承结构出现变化，出现“罕见陷阱（Uncommon Trap）”时，可以通过逆优化（Deoptimization）退回到解释状态继续执行 
   (部分没有解释器的虚拟机，也会采用不进行激进优化的C1编译器担任“逃生门”的角色)

   

2.2 解释器 - Interpreter

Interpreter解释执行class文件，好像JavaScript执行引擎一样

特殊的例子：

• 最早的Sun Classic VM只有Interpreter
• BEA JRockit VM则只有Compiler，但它主要面向服务端应用，部署在其上的应用不重点关注启动时间

2.3 编译器 - Compiler

只说HotSpot JVM

1. C1和C2：

HotSpot虚拟机内置了两个即时编译器，分别称为Client Compiler和Server Compiler，习惯上将前者称为C1，后者称为C2

2. 使用C1还是C2？

HotSpot默认采用解释器和其中一个编译器直接配合的方式工作，使用那个编译器取决于虚拟机运行的模式，HotSpot会根据自身版本和宿主机器硬件性能自动选择模式，用户也可以使用“-client”或”-server”参数去指定

1. 混合模式（Mixed Mode） 
   默认的模式，如上面描述的这种方式就是mixed mode

2. 解释模式（Interpreted Mode） 
   可以使用参数“-Xint”，在此模式下全部代码解释执行

3. 编译模式（Compiled Mode） 
   参数“-Xcomp”，此模式优先采用编译，但是无法编译时也会解释（在最新的HotSpot中此参数被取消）

   可以看到，我的JVM现在是mixed mode 
   

重要：↓

在JDK1.7（1.7仅包括Server模式）之后，HotSpot就不是默认“采用解释器和其中一个编译器”配合的方式了，而是采用了分层编译，分层编译时C1和C2有可能同时工作

3. 分层编译

3.1 为什么要分层编译？

由于编译器compile本地代码需要占用程序时间，要编译出优化程度更高的代码所花费的时间可能更长，且此时解释器还要替编译器收集性能监控信息，这对解释执行的速度也有影响

所以，为了在程序启动响应时间与运行效率之间达到最佳平衡，HotSpot在JDK1.6中出现了分层编译（Tiered Compilation）的概念并在JDK1.7的Server模式JVM中作为默认策略被开启

3.2 编译层 tier（或者叫级别）

分层编译根据编译器编译、优化的规模与耗时，划分了不同的编译层次（不只以下3种），包括：

• 第0层，程序解释执行（没有编译），解释器不开启性能监控功能，可触发第1层编译。

• 第1层，也称C1编译，将字节码编译为本地代码，进行简单、可靠的优化，如有必要将加入性能监控的逻辑

• 第2层（或2层以上），也称为C2编译，也是将字节码编译为本地代码，但是会启用一些编译耗时较长的优化，甚至会根据性能监控信息进行一些不可靠的激进优化

实施分层编译后，C1和C2将会同时工作，许多代码会被多次编译，用C1获取更高的编译速度，用C2来获取更好的编译质量，且在解释执行的时候解释器也无须再承担收集性能监控信息的任务

4. 编译对象与触发条件

1. 谁被编译了？

编译对象就是之前说的“热点代码”，它有两类：

1. 被多次调用的方法 
   
   • 一个方法被多次调用，理应称为热点代码，这种编译也是虚拟机中标准的JIT编译方式
2. 被多次执行的循环体 
   
   • 编译动作由循环体出发，但编译对象依然会以整个方法为对象；
   • 这种编译方式由于编译发生在方法执行过程中，因此形象的称为：栈上替换（On Stack Replacement- OSR编译，即方法栈帧还在栈上，方法就被替换了）

2. 触发条件

1. 综述

上面的方法和循环体都说“多次”，那么多少算多？换个说法就是编译的触发条件。

判断一段代码是不是热点代码，是不是需要触发JIT编译，这样的行为称为：热点探测（Hot Spot Detection），有几种主流的探测方式：

1. 基于计数器的热点探测（Counter Based Hot Spot Detection） 
   虚拟机会为每个方法（或每个代码块）建立计数器，统计执行次数，如果超过阀值那么就是热点代码。缺点是维护计数器开销。

2. 基于采样的热点探测（Sample Based Hot Spot Detection） 
   虚拟机会周期性检查各个线程的栈顶，如果某个方法经常出现在栈顶，那么就是热点代码。缺点是不精确。

3. 基于踪迹的热点探测（Trace Based Hot Spot Detection） 
   Dalvik中的JIT编译器使用这种方式

2. HotSpot

HotSpot使用的是第1种，因此它为每个方法准备了两类计数器：方法调用计数器（Invocation Counter）和回边计数器（Back Edge Counter）

1. 方法计数器

   • 默认阀值，在Client模式下是1500次，Server是10000次，可以通过参数“-XX:CompileThreshold”来设定

   • 当一个方法被调用时会首先检查是否存在被JIT编译过得版本，如果存在则使用此本地代码来执行；如果不存在，则将方法计数器+1，然后判断“方法计数器和回边计数器之和”是否超过阀值，如果是则会向编译器提交一个方法编译请求

   • 默认情况下，执行引擎并不会同步等待上面的编译完成，而是会继续解释执行。当编译完成后，此方法的调用入口地址会被系统自动改写为新的本地代码地址

   • 还有一点，热度是会衰减的，也就是说不是仅仅+，也会-，热度衰减动作是在虚拟机的GC执行时顺便进行的

2. 回边计数器

   • 回边，顾名思义，只有执行到大括号”}”时才算+1

   • 默认阀值，Client下13995，Server下10700

   • 它的调用逻辑和方法计数器差不多，只不过遇到回边指令时+1、超过阀值时会提交OSR编译请求以及这里没有热度衰减

5. 编译过程

编译过程是在后台线程（daemon）中完成的，可以通过参数“-XX:-BackgroundCompilation”来禁止后台编译，但此时执行线程就会同步等待编译完成才会执行程序

1. Client Compiler 
   C1编译器是一个简单快速的三段式编译器，主要关注“局部性能优化”，放弃许多耗时较长的全局优化手段 
   过程：class -> 1. 高级中间代码 -> 2. 低级中间代码 -> 3. 机器代码
2. Server Compiler 
   C2是专门面向服务器应用的编译器，是一个充分优化过的高级编译器，几乎能达到GNU C++编译器使用-O2参数时的优化强度。

使用参数“-XX:+PrintCompilation”会让虚拟机在JIT时把方法名称打印出来，如图： 

6. Java和C/C++的编译器对比

这里不是比Java和C/C++谁快这种大坑问题，只是比较编译器（我认为开发效率上Java快，执行效率上C/C++快）

这种对比代表了经典的即时编译器与静态编译期的对比，其实总体来说Java编译器有优有劣。主要就是动态编译时间压力大能做的优化少，还要做一些动态校验。而静态编译器无法实现一些开发上很有用的动态特性

JVM自动监控这所有方法的执行，如果某个方法是热点方法，JVM就计划把该方法的字节码代码编译成本地机器代码，编译成机器代码的过程是在独立线程中执行的，不会影响程序的执行，这个过程就是JIT（just in time）。

JIT针对下面的几种方式进行优化

• 把bytecode编译成本地代码
• 单态调度（monomorphic dispatch），当个对象的类和其父类间有方法重写时，JVM调用对象的方法可以通过对象的类型路径来判断应该调用父类的方法还是子类的方法，对此JIT进行优化，这种优化是C++所不具备的，C++中需要查找虚函数表。
• 循环展开（loop unrolling）
• 类型锐化
• 逃逸分析（escape analysis）
• 移除无用代码（这个现在IDE会提示我们的，比如：intellij idea）
• Intrinsics
• 分支预测
• 方法内联（inlining，对性能的提升很大），默认情况，<= 35字节码的方法可以进行内联，通过这个来修改内联方法的最大值：-XX:MaxInlineSize=，通过-XX:FreqInlineSize=来设置频繁调用方法的临界值

这些优化方法通常是层层依赖的，所以当JIT优化后的代码被JVM应用，就会开始尝试进行更上一层次的优化。因此我们写代码的时候，应该尽量往这些优化方式上面靠。

输出JIT编译过的方法

在JVM启动参数中添加如下的启动参数：

-XX:+PrintCompilation 

输出内容类似这样：

31    23 s!    sun.misc.URLClassPath::getLoader (136 bytes) 

• 第1列  31：为JVM启动后到该方法被编译相隔的时间，单位为毫秒
• 第2列  23：编译ID，用来跟踪一个方法的编译、优化、深度优化
• 第3列  s!：s是指该方法是synchronized，感叹号是指该方法有对异常的处理
• 第4列  sun.misc.URLClassPath::getLoader：被编译的方法
• 第5列  (136 bytes)：方法的字节大小

输出JIT编译的细节信息

通过添加参数-XX:+PrintCompilation，可以看到的信息其实并不具体，比如：那些方法进行了内联，内联后的二进制代码是怎么样的都没有。而要输出JIT编译的细节信息，就需要在JVM启动参数中添加这个参数：

-XX:+LogCompilation -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+PrintAssembly 

输出的编译信息，默认情况是在启动JVM的目录下一个名为：hotspot_pid<PID>.log的文件

如果想指定文件路径和文件名的话，可以再添加一个启动参数：

-XX:LogFile=<pathto file> 

输出的是一个很大的xml文件，可能有几百兆，内容大致如下：

<nmethodcompile_id='2' compiler='C1' level='3'  entry='0x00000001023fe240' size='1224'  address='0x00000001023fe0d0' relocation_offset='288'  insts_offset='368' stub_offset='880' scopes_data_offset='1032'  scopes_pcs_offset='1104' dependencies_offset='1200'  nul_chk_table_offset='1208'  method='java/lang/String hashCode ()I' bytes='55' count='512'  backedge_count='8218' iicount='512' stamp='0.350'/> 

而且内容很难读懂，建议使用JITWatch（ https://github.com/AdoptOpenJDK/jitwatch/ ）的可视化界面来查看JIT编译的细节信息。同时JITWatch还可以给出很多优化建议，给我们有效的优化代码提供参考，详见下文。

JIT编译模式

C1: 通常用于那种快速启动的GUI应用，对应启动参数：－client

C2: 通常用于长时间允许的服务端应用，对应启动参数：－server

分层编译模式（tiered compilation）：这是自从Java SE 7以后的新特性，可通过添加启动参数来开启：

-XX:+TieredCompilation 

这个特性在应用启动阶段使用C1模式以达到快速启动的效果，一旦应用程序运行起来以后，C2模式将取代C1模式，以进行更深度的优化。在Java SE 8中，这个特性是默认的。

JITWatch

前面也提到了，JITWatch可以通过可视化界面来帮助我们分析JVM输出的JIT编译输出日志，还可以帮助我们静态分析jar中的代码是否符合JIT编译优化的条件，还可以以曲线图形的方式展示JIT编译的整个过程中的一些指标，非常好用的工具。

下载

JITWatch需要在github上把代码clone下来，然后用maven来运行，地址为： https://github.com/AdoptOpenJDK/jitwatch/

运行JITWwatch

在代码根目录下执行 launchUI.sh（ Linux/Mac）或则 launchUI.bat（windows）

如果你使用maven，也可以在代码根目录下这样运行（其他运行方式，请参考JITWatch的github首页）

mvncleancompileexec:java 

如果你使用的是mac，而且idk版本是jdk7，且运行mvn clean compile exec:java时出现下面的错误和异常时： 

Causedby: java.lang.NullPointerException  atcom.sun.t2k.MacFontFinder.initPSFontNameToPathMap(MacFontFinder.java:339)  atcom.sun.t2k.MacFontFinder.getFontNamesOfFontFamily(MacFontFinder.java:390)  atcom.sun.t2k.T2KFontFactory.getFontResource(T2KFontFactory.java:233)  atcom.sun.t2k.LogicalFont.getSlot0Resource(LogicalFont.java:184)  atcom.sun.t2k.LogicalFont.getSlotResource(LogicalFont.java:228)  atcom.sun.t2k.CompositeStrike.getStrikeSlot(CompositeStrike.java:86)  atcom.sun.t2k.CompositeStrike.getMetrics(CompositeStrike.java:132)  atcom.sun.javafx.font.PrismFontUtils.getFontMetrics(PrismFontUtils.java:31)  atcom.sun.javafx.font.PrismFontLoader.getFontMetrics(PrismFontLoader.java:466)  atjavafx.scene.text.Text.<init>(Text.java:153)  atcom.sun.javafx.scene.control.skin.Utils.<clinit>(Utils.java:52)  ... 13 more   [ERROR] Failedto executegoalorg.codehaus.mojo:exec-maven-plugin:1.5.0:java (default-cli) onprojectjitwatch-ui: Anexceptionoccuredwhile executingtheJavaclass. null: InvocationTargetException: Exceptionin Applicationstartmethod: ExceptionInInitializerError: NullPointerException -> [Help 1] 

请在org.adoptopenjdk.jitwatch.launch.LaunchUI类的main函数开头处添加下面的代码（或者直接使用我fork修改好的 JITWatch ）：

final Class<?> macFontFinderClass = Class.forName("com.sun.t2k.MacFontFinder"); final java.lang.reflect.FieldpsNameToPathMap = macFontFinderClass.getDeclaredField("psNameToPathMap"); psNameToPathMap.setAccessible(true); if (psNameToPathMap.get(null) == null) {     psNameToPathMap.set(         null, new java.util.HashMap<String, String>()); } final java.lang.reflect.FieldallAvailableFontFamilies = macFontFinderClass.getDeclaredField("allAvailableFontFamilies"); allAvailableFontFamilies.setAccessible(true); if (allAvailableFontFamilies.get(null) == null) {     allAvailableFontFamilies.set(         null, new String[] {}); } 

然后重新运行即可看到JITWatch的界面。

Reference

http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

https://www.chrisnewland.com/images/jitwatch/HotSpot_Profiling_Using_JITWatch.pdf

如果你想在命令行界面监控网络吞吐量，nload 应用程序是个不错的选择。它是一个实时监控网络流量和带宽使用的控制台应用程序，使用两个图表可视化地展示接收和发送的流量，并提供诸如数据交换总量、最小/最大网络带宽使用量等附加信息。

安装

在 CentOS/RHEL/Red Hat/Fedora Linux 上安装 nload

首先在 CentOS 或者基于 RHEL 的操作系统上启用 EPEL 仓库，然后键入 yum 命令安装 nload：

# yum install nload

在 Debian 或者 Ubuntu Linux 上安装 nload

键入 apt-get 命令：

$ sudo apt-get install nload

在 FreeBSD 操作系统上安装 nload

通过 port 安装 nload，键入：

# cd /usr/ports/net/nload/ && make install clean

或者添加包

# pkg install net/nload

在 OpenBSD 操作系统上安装 nload

键入下列命令：

$ sudo pkg_add -i nload

在类 Unix 操作系统上从源代码安装 nload

首先，使用 wget 或者 curl 命令获取源代码：

$ cd /tmp
$ wget http://www.roland-riegel.de/nload/nload-0.7.4.tar.gz

使用 tar 命令解压缩名为 nload-0.7.4.tar.gz 的 tar 包，键入：

$ tar xvf nload-0.7.4.tar.gz

使用 cd 命令进入 nload 源代码所在目录：

$ cd nload*

然后键入 ./configure 为你的操作系统配置安装包：

$ sh ./configure

或者

$ ./configure

运行 configure 命令需要一点时间。完成后，使用 make 命令编译 nload：

$ make

最后，键入 make install 命令以 root 用户身份安装 nload 应用程序和相关文件：

$ sudo make install

或者

# make install

使用

如何使用 nload 显示当前网络使用量呢？

基本语法是：

nload
nload device
nload [options] device1 device2

键入下列命令：

$ nload
$ nload eth0
$ nload em0 em2

会得到输出：

图01: 使用 nload 命令

操控 nload 应用程序

nload 命令一旦执行就会开始监控网络设备，你可以使用下列快捷键操控 nload 应用程序。

1. 你可以按键盘上的 ← → 或者 Enter/Tab 键在设备间切换。
2. 按 F2 显示选项窗口。
3. 按 F5 将当前设置保存到用户配置文件。
4. 按 F6 从配置文件重新加载设置。
5. 按 q 或者 Ctrl+C 退出 nload。

设置显示刷新间隔

默认每 100 毫秒刷新一次显示数值，下面的例子将时间间隔设置成 500 毫秒：

$ nload -t {interval_number_in_millisec}
$ nload -t 500

输出：

Animated gif 01 - nload command in action

GIF 动画 01 - 使用 nload 命令

设置流量数值显示的单位

语法如下：

$ nload -u h|H|b|B|k|K|m|M|g|G
$ nload -U h|H|b|B|k|K|m|M|g|G
$ nload -u h
$ nload -u G
$ nload -U G

释义：

• 小写选项 -u: h 意为自动格式化为人类易读的单位，b 意为 Bit/s，k 意为 kBit/s，m 意为 MBit/s，g 意为 GBit/s。大写字母意为使用 Byte 替代 Bit。默认为 k。
• 大写选项 -U 与小写选项 -u 非常相似，不同之处在于它展示的是数据量，比如 Bit, kByte, GBit 等等。（没有 "/s"）。默认值是 M。

结论

我觉得 nload 是一个稳定可靠的应用程序，如果你喜欢 nload，你可能也想试试 Linux 和其他类 Unix 操作系统环境下的 vnstat 与 iftop 工具。

译自: http://www.cyberciti.biz/networking/nload-linux-command-to-monitor-network-traffic-bandwidth-usage/

FlameGraph

火焰图 ，简单通过x轴横条宽度来度量时间指标，y轴代表线程栈的层次，简单明了， 容易找出具体的可有化点，非常方便，当然前提是我们通过profiler工具获取到profiler 数据。

make BITS=64 all

-agentpath:path/to/liblagent.so[:file=name]

Comet 服务器是一类逻辑相对简单, 需要高并发连接的服务器. Comet 在网站系统中的应用非常广泛, 可以见这篇日志的介绍: http://www.ideawu.net/blog/archives/737.html.

HTTP 协议处理

要开发一个支持百万并发连接的 Comet 服务器, 我选择 C/C++ 语言, 当然还有其它的选择如 Erlang, Java 等. 对于一个只支持 long-polling Comet 服务器, 首先要具备解析 HTTP 协议的能力, 我选择 libevent 来处理 HTTP 协议.

通道和订阅者管理

服务器在启动的时候, 就预先分配了 100 万个通道对象的空间, 但订阅者对象是按需分配的, 通过内存池方式. 100 万个通道对象和程序的其它数据占用了 24MB 的内存.

Benchmark

启动 icomet 服务器:

./icomet 

服务器监听了 100 个端口, 是为了测试方便, 原因见前一篇文章的分析: 构建C1000K的服务器(1) – 基础.

然后启动 benchmark 客户端:

./tools/benchmark 127.0.0.1 8100 

benchmark 程序每创建十万个连接, 就会暂停, 按回车后继续. 通过 top/ps 查看 icomet 进程的内存占用. 最终, 得出如下数据.

可以看到, 每一个 Comet 连接大约占用了 2.7KB 的内存. 此时, 服务器空闲, 进程占用 CPU 为 0%.

项目的代码在: https://github.com/ideawu/icomet, 欢迎大家试用, 并反馈你的测试数据.

Related posts:

1. HTTP 长连接技术 Comet
2. 构建C1000K的服务器(1) – 基础
3. iComet 的一个应用场景
4. 长连接技术的应用

Few people will argue that asynchronous computation is cool and useful. In fact, the wholereactive programming idea is based on asynchronous computations being possible. Well, there’s more than that, but the core idea is to allow data and events to flow through your system and do something with the results when they become available.

So let’s look at an example of asynchronous function that everyone has seen and many have written themselves.

$("#book").fadeIn("slow",    function() {    console.log(“hurray”);   }); 

This piece of JavaScript code takes a book element and fades it in. When fading is complete a callback function is called and “hurray” string appears in the console. All is well and good in this trivial case, but once your system grows you can find yourself writing more and more of these nested callbacks.

Callbacks are a common way of dealing with asynchronous or delayed actions. They are not the best option though; the problem with callbacks is that they tend to chain forever, callbacks for callbacks for callbacks, until you find yourself in a complete mess and every change in the code becomes extremely painful and slow.

Maybe there are other ways to organize asynchronous code? In fact, there are: all you need to do is just tweak the perspective a bit. Imagine, if you had a type to represent a result of an async computation. It would be awesome, and your code would pass it around like every other value and be flat, fluid and readable.

Well, why don’t we build it!

When we’re done, we’ll have a monadic type Promise written in Java 8 that will make our asynchronous code wonderful. It’s not like it wasn’t ever done before, but I want to lead you through the process and help you understand what’s happening and why. If you are lazy or just prefer starting from code, check out the github repo.

Getting to love monads in 9.5 minutes

Oh, monads! Every programmer worth their morning coffee has written about them. Monads are what functional programming adepts love, use and praise. And there are thousands of tutorials and posts describing the concept.

So if you know everything there is to know about monads and want to get a closer look onto more interesting things, scroll down to the code below. Otherwise, bear with me just ten minutes, maybe this will become your go-to explanation about what a monad is.

A monad is a type, that represents a context of computation. I bet you’ve heard that before, but have you thought about what it means?

First of all, a monad doesn’t specify what is happening, that’s the responsibility of the computation within the context. A monad says what surrounds the computation that is happening.

Now, if you want an image reference to help you out, you can think of a monad as a bubble. Some people prefer a box, but a box is something concrete so a bubble works better for me.

These monad-bubbles have two properties:

• a bubble can surround something
• a bubble can receive instructions about what should it do with a surrounded thing

The surrounding part is easy to model in a programming language. Just take something and return a bubble! A constructor or a factory method comes to mind immediately here. Let’s look at how it is formalized. I’m assuming that you have some knowledge of Haskell notation (which you probably should have anyway). So the function that takes something and returns a monad is usually called pure or return:

return :: a -> m a 

Or in Java, if we can have some Monad class already.

public class Monad<T> {    public Monad(T t) {     …   } }

See that was easy. In fact, we’re halfway there. Another thing we must add is the ability to receive instructions for working with this value T eaten by our bubble.

What will help us is a bind function, which takes some form of an action and returns a different monad bubble that wraps this action executed on whatever was previously in the bubble.

For the sake of completeness, here is how it looks in Haskell.

(>>=)  :: m a -> (a -> m b) -> m b 

So this bind function takes a monad over a, (m a) and a function from a, and returns a different monad. In Java, we’ll have this definition as follows.

public class Monad<T> {    public abstract <V> Monad<V> bind(Function<T, Monad<V>> f); }

That will complete our generic definition of monads so we can proceed with an implementation.

Wait, what? I can have my monads in Java?

First of all, there are many different types of monads. In that sense, a monad is more like an interface in Java terms. There is a List monad, a Maybe monad, an IO monad (for languages that are very pure and cannot allow themselves to have normal IO), etc.

We will focus on creating a specific monad in Java, more specifically in Java 8. There is a good reason as to why we chose Java 8, since previously we found out that a monad will have to manipulate functions, which is really not that enjoyable in pre-lambda versions of Java.  However, Java 8 introduces lambdas and first-class methods, so it will be much more pleasant to work with them.

Your homemade Promise implementation

Here we go, now we’ve established our goal to have a monadic type to represent async computations. We’ve got our tools, namely Java 8, and we are ready to hack.

What we want to have is a Promise class that represents a result of asynchronous computation, either successful or erroneous.

Let’s pretend that we already have some Promise class that accepts callbacks to execute when the main computation is finished. Luckily, we don’t have to pretend very much, there are many implementations of that available: Akka’s Future, Play’s promise and so forth.

For this post I’m using the one from Play Framework, in which case instances of Promise get redeemed when some thread calls invoke() or invokeWithException() methods. It also accepts callbacks in a form of Play’s Promise specific Action class arguments. Obviously, Promise has constructors already, but not only do I want to create new instances of Promise, I also want to mark them completed with a value immediately. Here is how I can do it.

public static <V> Promise<V> pure(final V v) {     Promise<V> p = new Promise<>();     p.invoke(v);     return p;   }

The returned Promise is already redeemed and is ready to provide us with a result of the computation, which is precisely the given value.

The bind implementation will look like something below. It takes a function and adds that as a callback to this instance. A callback will get a result of this computation and apply given function to it. Whatever that function application returns or throws is used to redeem the resultingPromise.

public <R> Promise<R> bind(final Function<V, Promise<R>> function) {     Promise<R> result = new Promise<>();      this.onRedeem(callback -> {       try {         V v = callback.get();         Promise<R> applicationResult = function.apply(v);         applicationResult.onRedeem(applicationCallback -> {           try {             R r = applicationCallback.get();             result.invoke(r);           }           catch (Throwable e) {             result.invokeWithException(e);           }         });       }       catch (Throwable e) {         result.invokeWithException(e);       }     });     return result;   } 

Both applying the given function and getting a result from this are wrapped into the try-catch blocks, so exceptions are propagated to the resulting instance of Promise, just as one might expect.

With these two constructs, it’s very easy to chain asynchronous computations while avoiding going deeper and deeper into the callback hell. In the following synthetic example, we do exactly that.

public static void example1()                      throws ExecutionException, InterruptedException {     Promise<String> promise = Async.submit(() -> {       String helloWorld = "hello world";       long n = 500;       System.out.println("Sleeping " + n + " ms example1");       Thread.sleep(n);       return helloWorld;     });     Promise<Integer> promise2 = promise.bind(string ->               Promise.pure(Integer.valueOf(string.hashCode())));     System.out.println("Main thread example2");     int hashCode = promise2.get();     System.out.println("HashCode = " + hashCode);   }

That is basically it. We’ve implemented a monadic type Promise to represent a result of an async action.

Production-ready completable future

For those of you who have beared with me this far, I just want to say some final words about the quality of this implementation. Naturally, the above-mentioned GitHub repository has some tests that are proving that in some contexts, this might all work. However, I wouldn’t recommend using those Promises in production.

One reason for that is that Java 8 already contains a class that represents a result of async computation and is monadic…, welcome, CompletableFuture!

It does exactly what we want it to do and features several methods that allow you to bind a function to the result of an existing computation. Moreover, it provides methods to apply a function or a consumer, which is a void function by the way, or a plain old Runnable.

• thenApply(Function<? super T,? extends U> fn)
• thenApplyAsync(Function<? super T,? extends U> fn)
• thenAccept(Consumer<? super T> block)
• thenAcceptAsync(Consumer<? super T> block)
• thenRun(Runnable action)
• thenRunAsync(Runnable action)

On top of that, methods that end on *Async will execute this function asynchronously using a common ForkJoin executor. Otherwise, you can also supply an executor of your own liking.

Conclusion

Hopefully, this post shed some light onto what a monad is and next time you are about write a callback, you might want to consider a different approach.

In the post above we’ve looked at what monads are and how one can implement monadic classes in Java 8. Monads are great help in organizing data flow through your code and we’ve shown it with an example of Promise monad that represents results of an asynchronous computation. All the code from this blogpost is available for pondering in the Github repo.

Stay tuned for my next post, in which I plan to cover how to use the javaflow library to implement asynchronous awaiting for the promise to return a result. So you can get even more reactive :-)

Get the PDF

Finagle uses a clean, simple, and safe concurrent programming model, based onFutures. This leads to safe and modular programs that are also simple to reason about.

Finagle clients and servers expose statistics for monitoring and diagnostics. They are also traceable through a mechanism similar to Dapper‘s (another Twitter open source project, Zipkin, provides trace aggregation and visualization).

The quickstart has an overview of the most important concepts, walking you through the setup of a simple HTTP server and client.

A section on Futures follows, motivating and explaining the important ideas behind the concurrent programming model used in Finagle. The next section documents Services & Filters which are the core abstractions used to represent clients and servers and modify their behavior.

Other useful resources include:

• “Your Server as a Function” a paper motivating the core abstractions behind finagle (PLOS’13).
• Twitter engineering blog entry introducing Finagle
• ScalaDays 2011 presentation on Finagle
• Twitter’s Scala School has a section introducing Finagle and another constructing a distributed search engine using Finagle
• Alex Martins’ post on configuring fault tolerant Finagle clients (Part 1)

概述

通过执行以下命令，可以在1分钟内对系统资源使用情况有个大致的了解。

• uptime
• dmesg | tail
• vmstat 1
• mpstat -P ALL 1
• pidstat 1
• iostat -xz 1
• free -m
• sar -n DEV 1
• sar -n TCP,ETCP 1
• top

其中一些命令需要安装sysstat包，有一些由procps包提供。这些命令的输出，有助于快速定位性能瓶颈，检查出所有资源（CPU、内存、磁盘IO等）的利用率（utilization）、饱和度（saturation）和错误（error）度量，也就是所谓的USE方法。

下面我们来逐一介绍下这些命令，有关这些命令更多的参数和说明，请参照命令的手册。

uptime

$ uptime 23:51:26 up 21:31,  1 user,  load average: 30.02, 26.43, 19.02 

这个命令可以快速查看机器的负载情况。在Linux系统中，这些数据表示等待CPU资源的进程和阻塞在不可中断IO进程（进程状态为D）的数量。这些数据可以让我们对系统资源使用有一个宏观的了解。

命令的输出分别表示1分钟、5分钟、15分钟的平均负载情况。通过这三个数据，可以了解服务器负载是在趋于紧张还是区域缓解。如果1分钟平均负载很高，而15分钟平均负载很低，说明服务器正在命令高负载情况，需要进一步排查CPU资源都消耗在了哪里。反之，如果15分钟平均负载很高，1分钟平均负载较低，则有可能是CPU资源紧张时刻已经过去。

上面例子中的输出，可以看见最近1分钟的平均负载非常高，且远高于最近15分钟负载，因此我们需要继续排查当前系统中有什么进程消耗了大量的资源。可以通过下文将会介绍的vmstat、mpstat等命令进一步排查。

dmesg | tail

$ dmesg | tail [1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...] [1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child [1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB [2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request.  Check SNMP counters. 

该命令会输出系统日志的最后10行。示例中的输出，可以看见一次内核的oom kill和一次TCP丢包。这些日志可以帮助排查性能问题。千万不要忘了这一步。

vmstat 1

$ vmstat 1 procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----  r  b swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  0 32  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  0 32  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  0 32  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  0 32  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  1  1  0  0 ^C 

vmstat(8) 命令，每行会输出一些系统核心指标，这些指标可以让我们更详细的了解系统状态。后面跟的参数1，表示每秒输出一次统计信息，表头提示了每一列的含义，这几介绍一些和性能调优相关的列：

• r：等待在CPU资源的进程数。这个数据比平均负载更加能够体现CPU负载情况，数据中不包含等待IO的进程。如果这个数值大于机器CPU核数，那么机器的CPU资源已经饱和。
• free：系统可用内存数（以千字节为单位），如果剩余内存不足，也会导致系统性能问题。下文介绍到的free命令，可以更详细的了解系统内存的使用情况。
• si, so：交换区写入和读取的数量。如果这个数据不为0，说明系统已经在使用交换区（swap），机器物理内存已经不足。
• us, sy, id, wa, st：这些都代表了CPU时间的消耗，它们分别表示用户时间（user）、系统（内核）时间（sys）、空闲时间（idle）、IO等待时间（wait）和被偷走的时间（stolen，一般被其他虚拟机消耗）。

上述这些CPU时间，可以让我们很快了解CPU是否出于繁忙状态。一般情况下，如果用户时间和系统时间相加非常大，CPU出于忙于执行指令。如果IO等待时间很长，那么系统的瓶颈可能在磁盘IO。

示例命令的输出可以看见，大量CPU时间消耗在用户态，也就是用户应用程序消耗了CPU时间。这不一定是性能问题，需要结合r队列，一起分析。

mpstat -P ALL 1

$ mpstat -P ALL 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU) 07:38:49 PM  CPU   %usr  %nice   %sys %iowait   %irq  %soft  %steal  %guest  %gnice  %idle 07:38:50 PM  all  98.47   0.00   0.75    0.00   0.00   0.00    0.00    0.00    0.00   0.78 07:38:50 PM    0  96.04   0.00   2.97    0.00   0.00   0.00    0.00    0.00    0.00   0.99 07:38:50 PM    1  97.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   2.00 07:38:50 PM    2  98.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   1.00 07:38:50 PM    3  96.97   0.00   0.00    0.00   0.00   0.00    0.00    0.00    0.00   3.03 [...] 

该命令可以显示每个CPU的占用情况，如果有一个CPU占用率特别高，那么有可能是一个单线程应用程序引起的。

pidstat 1

$ pidstat 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU) 07:41:02 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command 07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0 07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave 07:41:03 PM     0      4354    0.94    0.94    0.00    1.89     8  java 07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java 07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java 07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat 07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command 07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave 07:41:04 PM     0      6521 1590.00    1.00    0.00 1591.00    27  java 07:41:04 PM     0      6564 1573.00   10.00    0.00 1583.00    28  java 07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass 07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat ^C 

pidstat命令输出进程的CPU占用率，该命令会持续输出，并且不会覆盖之前的数据，可以方便观察系统动态。如上的输出，可以看见两个JAVA进程占用了将近1600%的CPU时间，既消耗了大约16个CPU核心的运算资源。

iostat -xz 1

$ iostat -xz 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU) avg-cpu:  %user   %nice %system %iowait  %steal   %idle           73.96    0.00    3.73    0.03    0.06   22.21 Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util xvda        0.00     0.23    0.21    0.18     4.52     2.08    34.37     0.00    9.98   13.80    5.42   2.44   0.09 xvdb        0.01     0.00    1.02    8.94   127.97   598.53   145.79     0.00    0.43    1.78    0.28   0.25   0.25 xvdc        0.01     0.00    1.02    8.86   127.79   595.94   146.50     0.00    0.45    1.82    0.30   0.27   0.26 dm-0        0.00     0.00    0.69    2.32    10.47    31.69    28.01     0.01    3.23    0.71    3.98   0.13   0.04 dm-1        0.00     0.00    0.00    0.94     0.01     3.78     8.00     0.33  345.84    0.04  346.81   0.01   0.00 dm-2        0.00     0.00    0.09    0.07     1.35     0.36    22.50     0.00    2.55    0.23    5.62   1.78   0.03 [...] ^C 

iostat命令主要用于查看机器磁盘IO情况。该命令输出的列，主要含义是：

• r/s, w/s, rkB/s, wkB/s：分别表示每秒读写次数和每秒读写数据量（千字节）。读写量过大，可能会引起性能问题。
• await：IO操作的平均等待时间，单位是毫秒。这是应用程序在和磁盘交互时，需要消耗的时间，包括IO等待和实际操作的耗时。如果这个数值过大，可能是硬件设备遇到了瓶颈或者出现故障。
• avgqu-sz：向设备发出的请求平均数量。如果这个数值大于1，可能是硬件设备已经饱和（部分前端硬件设备支持并行写入）。
• %util：设备利用率。这个数值表示设备的繁忙程度，经验值是如果超过60，可能会影响IO性能（可以参照IO操作平均等待时间）。如果到达100%，说明硬件设备已经饱和。

如果显示的是逻辑设备的数据，那么设备利用率不代表后端实际的硬件设备已经饱和。值得注意的是，即使IO性能不理想，也不一定意味这应用程序性能会不好，可以利用诸如预读取、写缓存等策略提升应用性能。

free –m

$ free -m              total       used       free     shared    buffers     cached Mem:        245998      24545     221453         83         59        541 -/+ buffers/cache:      23944     222053 Swap:            0          0          0 

free命令可以查看系统内存的使用情况，-m参数表示按照兆字节展示。最后两列分别表示用于IO缓存的内存数，和用于文件系统页缓存的内存数。需要注意的是，第二行-/+ buffers/cache，看上去缓存占用了大量内存空间。这是Linux系统的内存使用策略，尽可能的利用内存，如果应用程序需要内存，这部分内存会立即被回收并分配给应用程序。因此，这部分内存一般也被当成是可用内存。

如果可用内存非常少，系统可能会动用交换区（如果配置了的话），这样会增加IO开销（可以在iostat命令中提现），降低系统性能。

sar -n DEV 1

$ sar -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015     _x86_64_    (32 CPU) 12:16:48 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil 12:16:49 AM      eth0  18763.00   5032.00  20686.42    478.30      0.00      0.00      0.00      0.00 12:16:49 AM        lo     14.00     14.00      1.36      1.36      0.00      0.00      0.00      0.00 12:16:49 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00 12:16:49 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil 12:16:50 AM      eth0  19763.00   5101.00  21999.10    482.56      0.00      0.00      0.00      0.00 12:16:50 AM        lo     20.00     20.00      3.25      3.25      0.00      0.00      0.00      0.00 12:16:50 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00 ^C 

sar命令在这里可以查看网络设备的吞吐率。在排查性能问题时，可以通过网络设备的吞吐量，判断网络设备是否已经饱和。如示例输出中，eth0网卡设备，吞吐率大概在22 Mbytes/s，既176 Mbits/sec，没有达到1Gbit/sec的硬件上限。

sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU) 12:17:19 AM  active/s passive/s    iseg/s    oseg/s 12:17:20 AM      1.00      0.00  10233.00  18846.00 12:17:19 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:20 AM      0.00      0.00      0.00      0.00      0.00 12:17:20 AM  active/s passive/s    iseg/s    oseg/s 12:17:21 AM      1.00      0.00   8359.00   6039.00 12:17:20 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:21 AM      0.00      0.00      0.00      0.00      0.00 ^C 

sar命令在这里用于查看TCP连接状态，其中包括：

• active/s：每秒本地发起的TCP连接数，既通过connect调用创建的TCP连接；
• passive/s：每秒远程发起的TCP连接数，即通过accept调用创建的TCP连接；
• retrans/s：每秒TCP重传数量；

TCP连接数可以用来判断性能问题是否由于建立了过多的连接，进一步可以判断是主动发起的连接，还是被动接受的连接。TCP重传可能是因为网络环境恶劣，或者服务器压力过大导致丢包。

top

$ top top - 00:15:40 up 21:56,  1 user,  load average: 31.09, 29.87, 29.92 Tasks: 871 total,   1 running, 868 sleeping,   0 stopped,   2 zombie %Cpu(s): 96.8 us,  0.4 sy,  0.0 ni,  2.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st KiB Mem:  25190241+total, 24921688 used, 22698073+free,    60448 buffers KiB Swap:        0 total,        0 used,        0 free.   554208 cached Mem    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND  20248 root      20   0  0.227t 0.012t  18748 S  3090  5.2  29812:58 java   4213 root      20   0 2722544  64640  44232 S  23.5  0.0 233:35.37 mesos-slave  66128 titancl+  20   0   24344   2332   1172 R   1.0  0.0   0:00.07 top   5235 root      20   0 38.227g 547004  49996 S   0.7  0.2   2:02.74 java   4299 root      20   0 20.015g 2.682g  16836 S   0.3  1.1  33:14.42 java      1 root      20   0   33620   2920   1496 S   0.0  0.0   0:03.82 init      2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd      3 root      20   0       0      0      0 S   0.0  0.0   0:05.35 ksoftirqd/0      5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H      6 root      20   0       0      0      0 S   0.0  0.0   0:06.94 kworker/u256:0      8 root      20   0       0      0      0 S   0.0  0.0   2:38.05 rcu_sched 

top命令包含了前面好几个命令的检查的内容。比如系统负载情况（uptime）、系统内存使用情况（free）、系统CPU使用情况（vmstat）等。因此通过这个命令，可以相对全面的查看系统负载的来源。同时，top命令支持排序，可以按照不同的列排序，方便查找出诸如内存占用最多的进程、CPU占用率最高的进程等。

但是，top命令相对于前面一些命令，输出是一个瞬间值，如果不持续盯着，可能会错过一些线索。这时可能需要暂停top命令刷新，来记录和比对数据。

总结

排查Linux服务器性能问题还有很多工具，上面介绍的一些命令，可以帮助我们快速的定位问题。例如前面的示例输出，多个证据证明有JAVA进程占用了大量CPU资源，之后的性能调优就可以针对应用程序进行。

感谢徐川对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群（已满），InfoQ读者交流群（#2）

public static void main(String[] args) throws Exception{
Random random=new Random();
CaseObject object=new CaseObject();
boolean result=true;
while(result){
result=object.execute(random.nextInt(1000));
Thread.sleep(1000);
}
}

}
public class CaseObject{

private static int sleepTotalTime=0;

public boolean execute(int sleepTime) throws Exception{
System.out.println("sleep: "+sleepTime);
sleepTotalTime+=sleepTime;
Thread.sleep(sleepTime);
return true;
}

}
[/java]
如在程序运行的情况下，想知道调用CaseObject的execute方法的以下几种情况，在BTrace中可以这么做：
1、调用此方法时传入的是什么参数，返回的是什么值，当时sleepTotalTime是多少？
BTrace脚本如下：
[java]
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.*;

@BTrace public class TraceMethodArgsAndReturn{
@OnMethod(
clazz="CaseObject",
method="execute",
location=@Location(Kind.RETURN)
)
public static void traceExecute(@Self CaseObject instance,int sleepTime,@Return boolean result){
println("call CaseObject.execute");
println(strcat("sleepTime is:",str(sleepTime)));
println(strcat("sleepTotalTime is:",str(get(field("CaseObject","sleepTotalTime"),instance))));
println(strcat("return value is:",str(result)));
}
}
[/java]
然后直接执行btrace -cp btrace/build [pid] TraceMethodArgsAndReturn.java就可以了。
当程序中调用到caseobject的execute方法时，就会在btrace的console中输出相应的信息。
2、execute方法执行耗时是多久？
BTrace脚本如下：
[java]
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.*;

@BTrace public class TraceMethodExecuteTime{

@TLS static long beginTime;

@OnMethod(
clazz="CaseObject",
method="execute"
)
public static void traceExecuteBegin(){
beginTime=timeMillis();
}

@OnMethod(
clazz="CaseObject",
method="execute",
location=@Location(Kind.RETURN)
)
public static void traceExecute(int sleepTime,@Return boolean result){
println(strcat(strcat("CaseObject.execute time is:",str(timeMillis()-beginTime)),"ms"));
}
}
[/java]
3、谁调用了execute方法？
BTrace脚本如下：
[java]
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.*;

@BTrace public class TraceMethodCallee{
@OnMethod(
clazz="CaseObject",
method="execute"
)
public static void traceExecute(){
println("who call CaseObject.execute :");
jstack();
}
}
[/java]
4、有没有人调用CaseObject中的哪一行代码？
BTrace脚本如下：
[java]
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.*;

@BTrace public class TraceMethodLine{
@OnMethod(
clazz="CaseObject",
location=@Location(value=Kind.LINE,line=5)
)
public static void traceExecute(@ProbeClassName String pcn,@ProbeMethodName String pmn,int line){
println(strcat(strcat(strcat("call ",pcn),"."),pmn));
}
}
[/java]
从上面可看出，在有了BTrace后，要动态的跟踪代码的运行细节还是非常爽的，更多的细节的操作请大家查看BTrace的User Guide。

一、越来越多的并发连接数

现在的Web系统面对的并发连接数在近几年呈现指数增长，高并发成为了一种常态，给Web系统带来不小的挑战。以最简单粗暴的方式解决，就是增加Web系统的机器和升级硬件配置。虽然现在的硬件越来越便宜，但是一味地通过增加机器来解决并发量的增长，成本是非常高昂的。结合技术优化方案，才是更有效的解决方法。

并发连接数为什么呈指数增长？实际上，从这几年的用户基数上看，这个数量并没有出现指数增长，因此它并非主要原因。主要原因，还是web变得更复杂，交互更丰富所导致的。

1. 页面元素增多，交互复杂

Web页面元素越来越多，更为丰富。更多的资源元素，意味着更多的下载请求。Web系统的交互越来越复杂，交互场景和次数也大幅增加。以“www.qq.com”的首页为例子，刷新一次，大概会有244个请求。并且，在页面打开完成之后，还会有一些定时的查询或者上报请求持续运作。

目前的Http请求，为了减少反复的创建和销毁连接行为，通常都建立长连接（Connection keep-alive）。一经建立，这个连接会被保持住一段时间，被后续请求复用。然而，它也带来了另一个新的问题，连接的保持是会占用Web系统服务端资源的，如果不充分使用这个连接，会导致资源浪费。长连接被创建后，首批资源传输完毕，之后几乎没有数据交互，一直到超时时间，才会自动释放长连接占据的系统资源。

除此之外，还有一些Web需求本身就需要长期保持连接的，例如Web socket。

2. 主流的本浏览器的连接数在增加

面对越来越丰富的Web资源，主流浏览器并发连接数也在增加，同一个域下，早期的浏览器一般只有1-2个下载连接，而目前的主流浏览器通常在2-6个。增加浏览器并发连接数目，在需要下载资源比较多的场景下，可以加快页面的加载速度。更多的连接对浏览器加载页面元素是有好处的，在某些连接遭遇“网络阻塞”的情况下，其他正常的下载连接可以继续工作。

这样自然无形增加了Web系统后端的压力，更多的下载连接意味着占据了更多的Web服务器的资源。而在用户访问高峰期，自热而然就形成了“高并发”场景。这些连接和请求，占据了服务器的大量CPU和内存等资源。尤其在资源数目超过100+的网站页面中，使用更多的下载连接，非常有必要。

二、Web前端优化，降低服务端压力

在缓解“高并发”的压力，需要前端和后端的共同配合优化，才能达到最大效果。在用户第一线的Web前端，可以起到减少或者减轻Http请求的效果。

1. 减少Web请求

常用的实现方法是通过Http协议头中的expire或max-age来控制，将静态内容放入浏览器的本地缓存，在之后的一段时间里，不再请求Web服务器，直接使用本地资源。还有HTML5中的本地存储技术（LocalStorage），也被作为一个强大的数据本地缓存。

这种方案缓存后，根本不发送请求到Web服务器，大幅降低服务器压力，也带来了良好的用户体验。但是，这种方案，对首次访问的用户无效，同时，也影响部分Web资源的实时性。

2. 减轻Web请求

浏览器的本地缓存是存在过期时间的，一旦过期，就必须重新向服务器请求。这个时候，会有两种情形：

（1）服务器的资源内容没有更新，浏览器请求Web资源，服务器回复“可以继续使用本地缓存”。（发生通信，但是Web服务器只需要做简单“回复”）

（2）服务器的文件或者内容已经更新，浏览器请求Web资源，Web服务器通过网络传输新的资源内容。（发生通信，Web服务器需要完成复杂的传输工作）

这里的协商方式是通过Http协议的Last-Modified或Etag来控制，这个时候请求服务器，如果是内容没有发生变更的情况，服务器会返回304 Not Modified。这样的话，就不需要每次请求Web服务器都做复杂的传输完整数据文件的工作，只要简单的http应答就可以达到相同的效果。

虽然上述请求，起到“减轻”Web服务器的压力，但是连接仍然被建立，请求也发生了。

3. 合并页面请求

如果是比较老一些的Web开发者，应该会更有印象，在ajax盛行之前。页面大部分都是直接输出的，并没有这么多的ajax请求，Web后端将页面内容完全拼凑好了，再返回给前端。那个时候，页面静态化，是一个挺广泛的优化方式。后来，被交互更友好的ajax渐渐替代了，一个页面的请求也变得越来越多。

由于移动端的网络（2G/3G）比起PC宽带差很多，并且部分手机配置比较低，面对一个超过100个请求的网页，加载的速度会缓慢很多。于是，优化的方向又重新回到合并页面元素，减少请求数量：

（1）合并HTML展示内容。将CSS和JS直接嵌入到HTML页面内，不通过连接的方式引入。

（2）Ajax动态内容合并请求。对于动态内容，将10次Ajax请求合并为1次的批量信息查询。

（3）小图片合并，通过CSS的偏移量技术Sprites，将很多小图片合并为一张。这个优化方式，在PC端的Web优化中，也非常常见。

合并请求，减少了传输数据的次数，也就是相当于将它们从一个一个地请求，变为一次的“批量”请求。上述优化方法，到达“减轻”Web服务器压力的目的，减少了需要建立的连接。

三、 节约Web服务端的内存

前端的优化完成，我们就需要着眼于Web服务端本身。内存是Web服务器非常重要的资源，更多的内存通常意味着可以同时放入更多的工作任务。就Web服务占用内存而言，可以粗略划分：

（1）用来维持连接的基本内存，进程初始化时，会载入一些基础模块到内存。

（2）被传输的数据内容载入到各个缓冲区，占据的内存。

（3）程序执行过程中，申请和使用的内存。

如果维持一个连接，能够尽可能少占用内存，那么我们就可以维持更多的并发连接，从而让Web服务器支持更多的并发连接数。

Apache（httpd）是一个成熟并且古老的Web服务，而Apache的发展和演变，一直在追求做到这一点，它试图不断减少服务占据的内存，以支持更大的并发量。以Apache的工作模式的演变为视角，我们一起来看看，它们是如何优化内存的问题的。

1. prefork MPM，多进程工作模式

prefork是Apache最成熟和稳定的工作模式，即使是现在，仍然被广泛使用。主进程生成后，它先完成基础的初始化工作，然后，通过fork预先产生一批的子进程（子进程会复制父进程的内存空间，不需要再做基础的初始化工作）。然后等待服务，之所以预先生成，是为了减少频繁创建和销毁进程的开销。多进程的好处，是进程之间的内存数据不会相互干扰，同时，某个进程异常终止也不会影响其他进程。但是，就内存而言，每个httpd子进程占用了很多的内存，因为子进程的内存数据是复制父进程的。我们可以粗略认为，这里存在大量的“重复数据”被放在内存中。最终，导致我们能够生成的子进程最大数量是很有限。在面对高并发时，因为有不少Keep-alive的长连接，将这些子进程“霸占”住，很可能导致可用子进程耗尽。因此，prefork并不太适合高并发场景。

• 优点：成熟稳定，兼容所有新老模块。同时，不需要担心线程安全的问题。（例如，我们常用的mod_php，将PHP编译为Apache的子模块，就不需要支持线程安全）
• 缺点：一个服务进程占用很多内存。

2. worker MPM，多进程和多线程的混合模式

worker模式比起prefork，是使用了多进程和多线程的混合模式。它也预先fork了几个子进程（数量很少），然后每个子进程创建一些线程（其中包括一个监听线程）。每个请求过来，会被分配到1个线程来服务。线程比起进程会更轻量，因为线程通常会共享父进程的内存空间，因此，内存的占用会减少一些。在高并发的场景下，因为比起prefork更省内存，因此会有更多的可用线程。

但是，它并没有解决Keep-alive的长连接“霸占”线程的问题，只是对象变成了比较轻量的线程。

有些人会觉得奇怪，那么这里为什么不完全使用多线程呢，还要引入多进程？因为还需要考虑稳定性，如果一个线程挂了，会导致同一个进程下其他正常的子线程都挂了。如果全部采用多线程，某个线程挂掉，就导致整个Apache服务“全军覆没”。而目前的工作模式，受影响的只是Apache的一部分服务，而不是整个服务。

线程共享父进程的内存空间，减少了内存的占用，却又引起了新的问题。就是“线程安全”，多个线程修改共享资源导致的“竞争行为”，又强迫我们所使用的模块必须支持“线程安全”。因此，它有一定程度上增加Web服务的不稳定性。例如，mod_php所使用的PHP拓展，也同样需要支持“线程安全”，否则，不能在该模式下使用。

• 优点：占据更少的内存，高并发下表现更优秀。
• 缺点：必须考虑线程安全的问题，同时锁的引入又增加了CPU的开销。

3. event MPM，多进程和多线程的混合模式，引入Epoll

这个是Apache中比较新的模式，在现在的版本（Apache 2.4.10）已经是稳定可用的模式。它和worker模式很像，最大的区别在于，它解决了keep-alive场景下，长期被占用的线程的资源浪费问题。event MPM中，会有一个专门的线程来管理这些keep-alive类型的线程，当有真实请求过来的时候，将请求传递给服务线程，执行完毕后，又允许它释放。它减少了“占据”连接而又不使用的资源浪费，增强了高并发场景下的请求处理能力。因为减少了“闲等”的线程，线程的数量减少，同等场景下，内存占用会下降一些。

event MPM在遇到某些不兼容的模块时，会失效，将会回退到worker模式，一个工作线程处理一个请求。新版Apache官方自带的模块，全部是支持event MPM的。注意一点，event MPM需要Linux系统（Linux 2.6+）对EPoll的支持，才能启用。Apache的三种模式中在真实应用场景中，event MPM是最节约内存的。

4. 使用比较轻量的Nginx作为Web服务器

虽然Apache的不断优化，减少了内存占用，从而增加了处理高并发的能力。但是，正如前面所说，Apache是一个古老而成熟的Web服务，同时，集成很多稳定的模块，是一个比较重的Web服务。Nginx是个比较轻量的Web服务，占据的内存天然就少于Apache。而且，Nginx通过一个进程来服务于N个连接。所使用的方式，并不是Apache的增加进程/线程来支持更多的连接。对于Nginx来说，它少创建了大量的进程/线程，减少了很多内存的开销。

静态文件的QPS性能压测结果，Nginx性能大概3倍于Apache对静态文件的处理。PHP等动态文件的QPS，Nginx的做法通常是通过FastCGI的方式和PHP-FPM通信的方式完成，PHP作为一个与之无关的外部服务存在。而Apache通常将PHP编译为自己的字模块（新版的Apache也支持FastCGI）。PHP动态文件，Nginx的表现略逊于Apache。

5. sendfile节约内存

Apache、Nginx等不少Web服务，都带有sendfile支持的。sendfile可以减少数据到“用户态内存空间”（用户缓冲区）的拷贝，进而减少内存的占用。当然，很多同学第一个反应当然是问Why？为了尽可能清楚讲述这个原理，我们就先回Linux内核态和用户态的存储空间的交互。

一般情况下，用户态（也就是我们的程序所在的内存空间）是不会直接读写或者操作各种设备（磁盘、网络、终端等），中间通常用内核作为“中间人”，来完成对设备的操作或者读写。

以最简单的磁盘读写例子，从磁盘中读取A文件，写入到B文件。A文件数据是从磁盘开始，然后载入到“内核缓冲区”，然后再拷贝到“用户缓冲区”，我们才可以对数据进行处理。写入的时候，也同理，从“用户态缓冲区”载入到“内核缓冲区”，最后写入到磁盘B文件。

这样写文件很累吧，于是有人觉得这里可以跳过“用户缓冲区”的拷贝。其实，这就是MMP（Memory-Mapping，内存映射）的实现，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区”，而是返回一个指向内存空间的指针。于是，我们之前的读写文件例子，就会变成，A文件数据从磁盘载入到“内核缓冲区”，然后从“内核缓冲区”复制到B文件的“内核缓冲区”，B文件再从”内核缓冲区“写回到磁盘中。这个过程，减少了一次内存拷贝，同时也少内存占用。

好了，回到sendfile的话题上来，简单的说，sendfile的做法和MMP类似，就是减少数据从”内核态缓冲区“到”用户态缓冲区“的内存拷贝。

默认的磁盘文件读取，到传输给socket，流程（不使用sendfile）是：

使用sendfile之后：

这种方式，不仅节省了内存，而且还有CPU的开销。

四、节约Web服务器的CPU

对Web服务器而言，CPU是另一个非常核心的系统资源。虽然一般情况下，我们认为业务程序的执行消耗了我们主要CPU。但是，就Web服务程序而言，多线程/多进程的上下文切换，也是比较消耗CPU资源的。一个进程/线程通常不能长期占有CPU，当发生阻塞或者时间片用完，就无法继续占用CPU，这个时候，就会发生上下文切换，CPU时间片从老进程/线程切换到新的。除此之外，在并发连接数目很高的场景下，对这些用户建立的连接（socket文件描述符）状态的轮询和检测，也是比较消耗CPU的。

而Apache和Nginx的发展和演变，也在努力减少CPU开销。

1. Select/Poll（Apache早期版本的I/O多路复用）

通常，Web服务都要维护很多个和用户通信的socket文件描述符，I/O多路复用，其实就是为了方便对这些文件描述符的管理和检测。Apache早期版本，是使用select的模式，简单的说，就是将这些我们关注的socket文件描述符交给内核，让内核告诉我们，那些描述符可操作。Poll与select原理基本相同，因此放在一起，它们之间的区别，就不赘叙了哈。

select/poll返回的是一个我们之前提交的文件描述符集合（内核将其中可读、可写或者异常状态的socket文件描述符的标识位修改了），我们需要通过轮询检查才能获得我们可以操作的文件描述符。在这个过程中，不断重复执行。在实际应用场景中，大部分被我们监控的socket文件描述符，都是”空闲的“，也就是说，不能操作。我们对整个集合轮询，就是为了找了少部分我们可以操作的socket文件描述符。于是，当我们监控的socket文件描述符越多（用户并发连接数越来越多），这个轮询工作，也就越来越沉重，进而导致增大了CPU的开销。

如果我们监控的socket文件描述符，几乎都是”活跃的“，反而使用这种模式更合适一点。

2. Epoll（新版的Apache的event MPM，Nginx等支持）

Epoll是Linux2.6开始正式支持的I/O多路复用，我们可以理解为它是对select/poll的改进。首先，我们同样将我们关注的socket文件描述符集合告诉给内核，同时，给它们注册”回调函数“，如果某个socket文件准备好了，就通过回调函数通知我们。于是，我们就不需要专门去轮询整个全量的socket文件描述符集合，直接可以得到已经可操作的socket文件描述符。那么，那些大部分”空闲“的描述符，我们就不遍历了。即使我们监控的socket文件描述越来越多，我们轮询的也只是”活跃可操作“的socket文件描述符。

其实，有一种极端点的场景，就是我们全部文件描述符几乎都是”活跃“的，这样反而导致了大量回调函数的执行，又增加了CPU的开销。但是，就Web服务的真实场景，绝大部分时候，都是连接集合中都存在很多”空闲“连接。

3. 线程/进程的创建销毁和上下文切换

通常，Apache某一个时间内，是一个进程/线程服务于一个连接。于是，Apache就有很多的进程/线程，服务于很多的连接。Web服务在高峰期，会建立很多的进程/线程，也就带来很多的上下文切换开销。而Nginx，它通常只有1个master主进程和几个worker子进程，然后，1个worker进程服务很多个连接，进而节省了CPU的上下文切换开销。

两种模式虽然不同，但实际上不能直接出分好坏，综合来说，各有各自的优势，就不妄议了哈。

4. 多线程下的锁对CPU的开销

Apache中的worker和event模式，都有采用多线程。多线程因为共享父进程的内存空间，在访问共享数据的时候，就会产生竞争，也就是线程安全问题。因此通常会引入锁（Linux下比较常用的线程相关的锁有互斥量metux，读写锁rwlock等），成功获取锁的线程可以继续执行，获取失败的通常选择阻塞等待。引入锁的机制，程序的复杂度往往增加不少，同时还有线程“死锁”或者“饿死”的风险（多进程在访问进程间共享资源的时候，也有同样的问题）。

死锁现象（两个线程彼此锁住对方想要获取的资源，相互阻塞等待，永远无法达不到满足条件）：

饿死现象（某个线程，一直获取不到它想要锁资源，永远无法执行下一步）：

为了避免这些锁导致的问题，就不得不加大程序的复杂度，解决方案一般有：

（1）对资源的加锁，根据约定好的顺序，大家都先对共享资源X加锁，加锁成功之后才能加锁共享资源Y。

（2）如果线程占有资源X，却加锁资源Y失败，则放弃加锁，同时也释放掉之前占有的资源X。

在使用PHP的时候，在Apache的worker和event模式下，也必须兼容线程安全。通常，新版本的PHP官方库是没有线程安全方面的问题，需要关注的是第三方扩展。PHP实现线程安全，不是通过锁的方式实现的。而是为每个线程独立申请一份全局变量的副本，相当于线程的私人内存空间，但是这样做相对消耗多一些内存。不过，这样的好处，是不需要引入复杂的锁机制实现，也避免了锁机制对CPU的开销。

这里顺便提到一下，经常和Nginx搭配工作的PHP-FPM（FastCGI）使用的是多进程，因此不会有线程安全的问题。

五、 小结

可能有些同学看完之后，会得出结论，Nginx+PHP-FPM的工作方式，似乎是最节省系统资源的Web系统工作方式。某种程度上说，的确是可以这么说的，但是Web系统的搭建，需要从实际业务应用的角度出发，具体问题需要具体分析，寻求最合适的技术方案。

Web服务的不断演变和发展，努力地追求用尽可能少的系统资源，来支撑更多的用户请求，这是一条波澜壮阔的前进之路。这些技术方案，汇聚了很多值得学习和借鉴的解决问题的思路。

Thrift在0.9.1版本之前，一直只提交了对单一接口服务的支持，即一个RPC服务器（对应一个端口）支持一个服务接口的实现。

但是很多时候，我们的服务不能实现在一个接口里，一是接口里的方法越来越多，不好管理和使用；二是根据职责的单一要求，不能类型的方法，不能放在同一接口里。

在 Thrift-0.9.1之前，我们要解决上面的问题，一是通过多个RPC服务器来实现，这个方法必然导致了我们RPC服务器越来越多，管理上麻烦；二是通过其他的一些途径，如使用netty作为RPC服务器等，这个方法实现上相对麻烦一些，需要去了解netty的知识。

这些方法在这里就不再详述了。

从Thrift-0.9.1开始，thrift开始提供对多接口服务的支持，使得我们开发多接口RPC服务相对简单多了。

这里还是给出例子来说明。

首先，我们做了两个接口定义文件来定义两个接口：

namespace javacom.eli.test.service

struct Topic

{

    1: i32 uid,

    2: string name,

    3: string content

}

service TopicService

{

    void store(1: Topic topic),

    Topic retrieve(1: i32 uid)

}

namespace javacom.eli.test.service

struct User

{

    1: i32 uid,

    2: string name,

    3: string blurb

}

service UserService

{

    void store1(1: User user),

    User retrieve1(1: i32 uid)

}

然后使用Thrift-0.9.1.exe生成相应的JavaBean及接口：

然后，我们写两个接口的实现类：

import org.apache.thrift.TException;

import com.eli.test.service.Topic;

import com.eli.test.service.TopicService;

public class TopicImpl implements TopicService.Iface{

public void store(Topic topic)throws TException

{

        System.out.println("theinput topic: ");

        System.out.println("id:"+topic.getUid());

        System.out.println("name:"+topic.getName());

        System.out.println("content:"+topic.getContent());

}

public Topic retrieve(int uid)throws TException

{

        System.out.println("theinput uid: "+uid);

        return newTopic(uid,"test","test");

}

}

import org.apache.thrift.TException;

import com.eli.test.service.User;

import com.eli.test.service.UserService;

public class UserImpl implements UserService.Iface{

public void store1(User user)throws TException

{

        System.out.println("theinput user: ");

        System.out.println("uid:"+user.getUid());

        System.out.println("name:"+user.getName());

        System.out.println("blur:"+user.getBlurb());

}

public User retrieve1(int uid)throws TException

{

        System.out.println("theinput uid: "+uid);

        return newUser(uid,"tom","123");

}

}

上述工作完成以后，就可以写服务器代码了。

服务器代码与单一接口的服务器代码最大的不同是使用了“TMultiplexedProcessor”类，通过该类，可以注册多个接口的服务实现类：

TMultiplexedProcessor processor = new TMultiplexedProcessor();

       processor.registerProcessor("TopicService", newTopicService.Processor<TopicService.Iface>(newTopicImpl()));

    processor.registerProcessor("UserService", new UserService.Processor<UserService.Iface>(new UserImpl()));

其他代码就跟以前的服务器代码一样了。

完整的服务器代码如下：

TMultiplexedProcessor processor = newTMultiplexedProcessor();

           TServerTransport t = new TServerSocket(9090);

           TServer server = new TThreadPoolServer(newTThreadPoolServer.Args(t).processor(processor));

           processor.registerProcessor("TopicService", newTopicService.Processor<TopicService.Iface>(newTopicImpl()));

           processor.registerProcessor("UserService", newUserService.Processor<UserService.Iface>(newUserImpl()));

//         TSimpleServer server = new TSimpleServer(new Args(t).processor(processor));

           System.out.println("the serveris started and is listening at 9090...");

        server.serve();

最后是客户端代码了，客户端代码的不同之处是引入了“TMultiplexedProtocol”类，它来帮助客户端区别调用哪个接口：

TMultiplexedProtocol mp1 = new TMultiplexedProtocol(protocol,"TopicService");

    TopicService.Clientservice1 = new TopicService.Client(mp1);

完整的客户端测试代码如下：

              TSocket transport = new TSocket("localhost",9090);

              TBinaryProtocol protocol = new TBinaryProtocol(transport);

              TMultiplexedProtocolmp1 = new TMultiplexedProtocol(protocol,"TopicService");

              TopicService.Client service1 = newTopicService.Client(mp1);

              TMultiplexedProtocolmp2 = new TMultiplexedProtocol(protocol,"UserService");

              UserService.Client service2 = newUserService.Client(mp2);

              transport.open();

              service1.store(new Topic(668,"test topic","just a test!"));

              service2.store1(new User(888,"tom","haha"));

              System.out.println(service1.retrieve(168));

              System.out.println(service2.retrieve1(999));

           transport.close();

运行服务器代码和客户端代码，则客户端会打印如下结果：

Topic(uid:168, name:test, content:test)

User(uid:999, name:tom, blurb:123)

服务器端会打印如下的信息：

the server is started and is listening at 9090...

the input topic:

id: 668

name: test topic

content: just a test!

the input user:

uid: 888

name: tom

blur: haha

the input uid: 168

the input uid: 999

通过上面的例子，可以看到，Thrift-0.9.1版本很简单的解决了多接口服务的问题，随便说一下，该版本并没有解决所有语言的多接口实现问题，只是解决了Java和其他几个语言。请大家在使用的时候，查清楚您使用的语言是否解决了这个问题。

一、开启nginx的监控

1)、nginx简单状态监控

在nginx.conf中添加如下代码即可监控nginx当前的状态，然后访问http://serverip/status即可访问

location /status {
stub_status on;
access_log off;
}

一般显示为

Active connections: 16 
server accepts handled requests
191226 191226 305915 
Reading: 0 Writing: 1 Waiting: 15

ctive connections: 对后端发起的活动连接数.

Server accepts handled requests: Nginx总共处理了24个连接,成功创建24次握手(证明中间没有失败的),总共处理了129个请求.

Reading: Nginx 读取到客户端的Header信息数.

Writing: Nginx 返回给客户端的Header信息数.

操作系统:Centos6.3
Tomcat:7.0.42
JDK:1.6.0_45
配置:8G,4核.

最近tomcat负载比较高,默认的配置和bio的处理方式已经无力支撑.据说APR能提升50%~60%的性能,所以尝试下APR优化.
APR介绍:

Tomcat可以使用APR来提供超强的可伸缩性和性能，更好地集成本地服务器技术。  APR(Apache Portable Runtime)是一个高可移植库，它是Apache HTTP Server 2.x的核心。  APR有很多用途，包括访问高级IO功能(例如sendfile,epoll和OpenSSL)，OS级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，NT管道和UNIX sockets)。这些功能可以使Tomcat作为一个通常的前台WEB服务器，能更好地和其它本地web技术集成，总体上让Java更有效率作为一个高性能web服务器平台而不是简单作为后台容器。  在产品环境中，特别是直接使用Tomcat做WEB服务器的时候，应该使用Tomcat Native来提高其性能。

1. 服务器安装GCC

客户服务器连不上外网,服务器也没有gcc,所以先使用代理连接外网,修改/etc/yum.conf,加入代理配置:

proxy=http://10.103.0.46:808

如果需要验证加入用户名密码:

proxy_username=代理服务器用户名 proxy_password=代理服务器密码 

yum使用163的Centos源:参考http://mirrors.163.com/.help/centos.html
先备份

mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup 

然后下载CentOS6 放入到/etc/yum.repos.d/(操作前请做好相应备份)

运行以下命令生成缓存:

yum clean all yum makecache 

然后安装gcc:

yum -y install gcc 

2. 安装APR

从http://apr.apache.org/download.cgi下载apr,apr-util,apr-iconv. 因为服务器没有配置全局的http代理,只是yum代理,所以下载之后传到服务器即可.

传输完安装apr:

tar zxvf apr-1.5.1.tar.gz cd apr-1.5.1 ./configure --prefix=/usr/local/apr make make install 

安装apr-iconv:

tar zxvf apr-iconv-1.2.1.tar.gz cd apr-iconv-1.2.1 ./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr make make install 

安装apr-util:

tar zxvf apr-util-1.5.3.tar.gz cd apr-util-1.5.3 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv make   make install 

安装tomcat-native:首先到tomcat/bin目录下,找到对应的tar文件.

tar zxvf tomcat-native.tar.gz cd tomcat-native-1.1.27-src/jni/native/ ./configure --with-apr=/usr/local/apr --with-java-home=/usr/lib/jdk1.6.0_45 make make install 

安装完成之后 会出现如下提示信息

Libraries have been installed in: /usr/local/apr/lib 

添加环境变量: vi /etc/profile在文件末尾处添加下面的变量

export LD_LIBRARY_PATH=/usr/local/apr/lib 

然后执行下面命令，使环境变量即时生效

source /etc/profile 

以下为完整安装脚本:

#setup apr tar zxvf apr-1.5.1.tar.gz cd apr-1.5.1 ./configure --prefix=/usr/local/apr make && make install cd ../ #setup apr-iconv tar zxvf apr-iconv-1.2.1.tar.gz cd apr-iconv-1.2.1/ ./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr make && make install cd ../ #setup apr-util tar zxvf apr-util-1.5.3.tar.gz cd apr-util-1.5.3 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv make && make install #setup tomcat-native cd /app/apache-tomcat-7.0.42/bin tar zxvf tomcat-native.tar.gz cd tomcat-native-1.1.27-src/jni/native ./configure --with-apr=/usr/local/apr --with-java-home=/usr/lib/jdk1.6.0_45 make && make install cd / #LD_LIBRARY_PATH echo -e 'export LD_LIBRARY_PATH=/usr/local/apr/lib' >> /etc/profile export LD_LIBRARY_PATH=/usr/local/apr/lib source /etc/profile 

3. 配置Tomcat

修改tomcat配置conf/server.xml:

<!--The connectors can use a shared executor, you can define one or more named thread pools-->     <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"         maxThreads="800" minSpareThreads="400"/>        <!-- A "Connector" represents an endpoint by which requests are received          and responses are returned. Documentation at :          Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)          Java AJP  Connector: /docs/config/ajp.html          APR (HTTP/AJP) Connector: /docs/apr.html          Define a non-SSL HTTP/1.1 Connector on port 8080     -->     <Connector port="80" executor="tomcatThreadPool" protocol="org.apache.coyote.http11.Http11AprProtocol"                connectionTimeout="20000"                redirectPort="8443" enableLookups="false" acceptCount="1000"/> 

修改为Http11AprProtocol 协议.

之后启动tomcat即可.

遇到问题:

SEVERE: Failed to initialize the SSLEngine. org.apache.tomcat.jni.Error: 70023: This function has not been implemented on this platform 

请关闭SSL侦听，除非你有使用SSL,修改conf/server.xml

<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="off" /> 

压测结果:

webbench -c 4000 -t 30 http://10.103.10.140/workbench/index.jsp Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.  Benchmarking: GET http://10.103.10.140/workbench/index.jsp 4000 clients, running 30 sec.  Speed=484340 pages/min, 2441573 bytes/sec. Requests: 242170 susceed, 0 failed. 

参考:

http://www.chepoo.com/tomcat-performance-three-times-is-not-a-dream.html

http://rhomobi.com/topics/36

https://gitsea.com/2013/07/02/tomcat-%E5%B9%B6%E5%8F%91%E4%BC%98%E5%8C%96/

http://pengranxiang.iteye.com/blog/1128905

http://tomcat.apache.org/tomcat-7.0-doc/apr.html#Linux

http://www.cnblogs.com/wanghaosoft/archive/2013/02/04/2892099.html

1. 背景

1.1. Netty 3.X系列版本现状

根据对Netty社区部分用户的调查，结合Netty在其它开源项目中的使用情况，我们可以看出目前Netty商用的主流版本集中在3.X和4.X上，其中以Netty 3.X系列版本使用最为广泛。

Netty社区非常活跃，3.X系列版本从2011年2月7日发布的netty-3.2.4 Final版本到2014年12月17日发布的netty-3.10.0 Final版本，版本跨度达3年多，期间共推出了61个Final版本。

1.2. 升级还是坚守老版本

相比于其它开源项目，Netty用户的版本升级之路更加艰辛，最根本的原因就是Netty 4对Netty 3没有做到很好的前向兼容。

由于版本不兼容，大多数老版本使用者的想法就是既然升级这么麻烦，我暂时又不需要使用到Netty 4的新特性，当前版本还挺稳定，就暂时先不升级，以后看看再说。

坚守老版本还有很多其它的理由，例如考虑到线上系统的稳定性、对新版本的熟悉程度等。无论如何升级Netty都是一件大事，特别是对Netty有直接强依赖的产品。

从上面的分析可以看出，坚守老版本似乎是个不错的选择；但是，“理想是美好的,现实却是残酷的”，坚守老版本并非总是那么容易，下面我们就看下被迫升级的案例。

1.3. “被迫”升级到Netty 4.X

除了为了使用新特性而主动进行的版本升级，大多数升级都是“被迫的”。下面我们对这些升级原因进行分析。

1. 公司的开源软件管理策略：对于那些大厂，不同部门和产品线依赖的开源软件版本经常不同，为了对开源依赖进行统一管理，降低安全、维护和管理成本，往往会指定优选的软件版本。由于Netty 4.X 系列版本已经非常成熟，因为，很多公司都优选Netty 4.X版本。
2. 维护成本：无论是依赖Netty 3.X，还是Netty4.X，往往需要在原框架之上做定制。例如，客户端的短连重连、心跳检测、流控等。分别对Netty 4.X和3.X版本实现两套定制框架，开发和维护成本都非常高。根据开源软件的使用策略，当存在版本冲突的时候，往往会选择升级到更高的版本。对于Netty，依然遵循这个规则。
3. 新特性：Netty 4.X相比于Netty 3.X,提供了很多新的特性，例如优化的内存管理池、对MQTT协议的支持等。如果用户需要使用这些新特性，最简便的做法就是升级Netty到4.X系列版本。
4. 更优异的性能：Netty 4.X版本相比于3.X老版本，优化了内存池，减少了GC的频率、降低了内存消耗；通过优化Rector线程池模型，用户的开发更加简单，线程调度也更加高效。

1.4. 升级不当付出的代价

表面上看，类库包路径的修改、API的重构等似乎是升级的重头戏，大家往往把注意力放到这些“明枪”上，但真正隐藏和致命的却是“暗箭”。如果对Netty底层的事件调度机制和线程模型不熟悉，往往就会“中枪”。

本文以几个比较典型的真实案例为例，通过问题描述、问题定位和问题总结，让这些隐藏的“暗箭”不再伤人。

由于Netty 4线程模型改变导致的升级事故还有很多，限于篇幅，本文不一一枚举，这些问题万变不离其宗，只要抓住线程模型这个关键点，所谓的疑难杂症都将迎刃而解。

2. Netty升级之后遭遇内存泄露

2.1. 问题描述

随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty4.X提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。

业务应用的特点是高并发、短流程，大多数对象都是朝生夕灭的短生命周期对象。为了减少内存的拷贝，用户期望在序列化的时候直接将对象编码到PooledByteBuf里，这样就不需要为每个业务消息都重新申请和释放内存。

业务的相关代码示例如下：

//在业务线程中初始化内存池分配器，分配非堆内存  ByteBufAllocator allocator = new PooledByteBufAllocator(true);  ByteBuf buffer = allocator.ioBuffer(1024); //构造订购请求消息并赋值，业务逻辑省略 SubInfoReq infoReq = new SubInfoReq (); infoReq.setXXX(......); //将对象编码到ByteBuf中 codec.encode(buffer, info); //调用ChannelHandlerContext进行消息发送 ctx.writeAndFlush(buffer);

业务代码升级Netty版本并重构之后，运行一段时间，Java进程就会宕机，查看系统运行日志发现系统发生了内存泄露（示例堆栈）：

图2-1 OOM内存溢出堆栈

对内存进行监控（切换使用堆内存池，方便对内存进行监控），发现堆内存一直飙升，如下所示（示例堆内存监控）：

图2-2 堆内存监控

2.2. 问题定位

使用jmap -dump:format=b,file=netty.bin PID 将堆内存dump出来，通过IBM的HeapAnalyzer工具进行分析，发现ByteBuf发生了泄露。

因为使用了内存池，所以首先怀疑是不是申请的ByteBuf没有被释放导致？查看代码，发现消息发送完成之后，Netty底层已经调用ReferenceCountUtil.release(message)对内存进行了释放。这是怎么回事呢？难道Netty 4.X的内存池有Bug，调用release操作释放内存失败？

考虑到Netty 内存池自身Bug的可能性不大，首先从业务的使用方式入手分析：

1. 内存的分配是在业务代码中进行，由于使用到了业务线程池做I/O操作和业务操作的隔离，实际上内存是在业务线程中分配的；
2. 内存的释放操作是在outbound中进行，按照Netty 3的线程模型，downstream（对应Netty 4的outbound，Netty 4取消了upstream和downstream）的handler也是由业务调用者线程执行的，也就是说释放跟分配在同一个业务线程中进行。

初次排查并没有发现导致内存泄露的根因，一筹莫展之际开始查看Netty的内存池分配器PooledByteBufAllocator的Doc和源码实现，发现内存池实际是基于线程上下文实现的，相关代码如下：

final ThreadLocal<PoolThreadCache> threadCache = new ThreadLocal<PoolThreadCache>() {         private final AtomicInteger index = new AtomicInteger();         @Override         protected PoolThreadCache initialValue() {             final int idx = index.getAndIncrement();             final PoolArena<byte[]> heapArena;             final PoolArena<ByteBuffer> directArena;             if (heapArenas != null) {                 heapArena = heapArenas[Math.abs(idx % heapArenas.length)];             } else {                 heapArena = null;             }             if (directArenas != null) {                 directArena = directArenas[Math.abs(idx % directArenas.length)];             } else {                 directArena = null;             }             return new PoolThreadCache(heapArena, directArena);         }

也就是说内存的申请和释放必须在同一线程上下文中，不能跨线程。跨线程之后实际操作的就不是同一块内存区域，这会导致很多严重的问题，内存泄露便是其中之一。内存在A线程申请，切换到B线程释放，实际是无法正确回收的。

通过对Netty内存池的源码分析，问题基本锁定。保险起见进行简单验证，通过对单条业务消息进行Debug，发现执行释放的果然不是业务线程，而是Netty的NioEventLoop线程：当某个消息被完全发送成功之后，会通过ReferenceCountUtil.release(message)方法释放已经发送成功的ByteBuf。

问题定位出来之后，继续溯源，发现Netty 4修改了Netty 3的线程模型：在Netty 3的时候，upstream是在I/O线程里执行的，而downstream是在业务线程里执行。当Netty从网络读取一个数据报投递给业务handler的时候，handler是在I/O线程里执行；而当我们在业务线程中调用write和writeAndFlush向网络发送消息的时候,handler是在业务线程里执行，直到最后一个Header handler将消息写入到发送队列中，业务线程才返回。

Netty4修改了这一模型，在Netty 4里inbound(对应Netty 3的upstream)和outbound(对应Netty 3的downstream)都是在NioEventLoop(I/O线程)中执行。当我们在业务线程里通过ChannelHandlerContext.write发送消息的时候，Netty 4在将消息发送事件调度到ChannelPipeline的时候，首先将待发送的消息封装成一个Task，然后放到NioEventLoop的任务队列中，由NioEventLoop线程异步执行。后续所有handler的调度和执行，包括消息的发送、I/O事件的通知，都由NioEventLoop线程负责处理。

下面我们分别通过对比Netty 3和Netty 4的消息接收和发送流程，来理解两个版本线程模型的差异：

Netty 3的I/O事件处理流程：

图2-3 Netty 3 I/O事件处理线程模型

Netty 4的I/O消息处理流程：

图2-4 Netty 4 I/O事件处理线程模型

2.3. 问题总结

Netty 4.X版本新增的内存池确实非常高效，但是如果使用不当则会导致各种严重的问题。诸如内存泄露这类问题，功能测试并没有异常，如果相关接口没有进行压测或者稳定性测试而直接上线，则会导致严重的线上问题。

内存池PooledByteBuf的使用建议：

1. 申请之后一定要记得释放，Netty自身Socket读取和发送的ByteBuf系统会自动释放，用户不需要做二次释放；如果用户使用Netty的内存池在应用中做ByteBuf的对象池使用，则需要自己主动释放；
2. 避免错误的释放：跨线程释放、重复释放等都是非法操作，要避免。特别是跨线程申请和释放，往往具有隐蔽性，问题定位难度较大；
3. 防止隐式的申请和分配：之前曾经发生过一个案例，为了解决内存池跨线程申请和释放问题，有用户对内存池做了二次包装，以实现多线程操作时，内存始终由包装的管理线程申请和释放，这样可以屏蔽用户业务线程模型和访问方式的差异。谁知运行一段时间之后再次发生了内存泄露，最后发现原来调用ByteBuf的write操作时，如果内存容量不足，会自动进行容量扩展。扩展操作由业务线程执行，这就绕过了内存池管理线程，发生了“引用逃逸”。该Bug只有在ByteBuf容量动态扩展的时候才发生，因此，上线很长一段时间没有发生，直到某一天......因此，大家在使用Netty 4.X的内存池时要格外当心，特别是做二次封装时，一定要对内存池的实现细节有深刻的理解。

3. Netty升级之后遭遇数据被篡改

3.1. 问题描述

某业务产品，Netty3.X升级到4.X之后，系统运行过程中，偶现服务端发送给客户端的应答数据被莫名“篡改”。

业务服务端的处理流程如下：

1. 将解码后的业务消息封装成Task，投递到后端的业务线程池中执行；
2. 业务线程处理业务逻辑，完成之后构造应答消息发送给客户端；
3. 业务应答消息的编码通过继承Netty的CodeC框架实现，即Encoder ChannelHandler;
4. 调用Netty的消息发送接口之后，流程继续，根据业务场景，可能会继续操作原发送的业务对象。

业务相关代码示例如下：

//构造订购应答消息 SubInfoResp infoResp = new SubInfoResp(); //根据业务逻辑，对应答消息赋值 infoResp.setResultCode(0); infoResp.setXXX()； 后续赋值操作省略...... //调用ChannelHandlerContext进行消息发送 ctx.writeAndFlush(infoResp); //消息发送完成之后，后续根据业务流程进行分支处理，修改infoResp对象 infoResp.setXXX(); 后续代码省略......

3.2. 问题定位

首先对应答消息被非法“篡改”的原因进行分析，经过定位发现当发生问题时，被“篡改”的内容是调用writeAndFlush接口之后，由后续业务分支代码修改应答消息导致的。由于修改操作发生在writeAndFlush操作之后，按照Netty 3.X的线程模型不应该出现该问题。

在Netty3中，downstream是在业务线程里执行的，也就是说对SubInfoResp的编码操作是在业务线程中执行的，当编码后的ByteBuf对象被投递到消息发送队列之后，业务线程才会返回并继续执行后续的业务逻辑，此时修改应答消息是不会改变已完成编码的ByteBuf对象的，所以肯定不会出现应答消息被篡改的问题。

初步分析应该是由于线程模型发生变更导致的问题，随后查验了Netty 4的线程模型，果然发生了变化：当调用outbound向外发送消息的时候，Netty会将发送事件封装成Task，投递到NioEventLoop的任务队列中异步执行，相关代码如下：

@Override  public void invokeWrite(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) {         if (msg == null) {             throw new NullPointerException("msg");         }         validatePromise(ctx, promise, true);         if (executor.inEventLoop()) {             invokeWriteNow(ctx, msg, promise);         } else {             AbstractChannel channel = (AbstractChannel) ctx.channel();             int size = channel.estimatorHandle().size(msg);             if (size > 0) {                 ChannelOutboundBuffer buffer = channel.unsafe().outboundBuffer();                 // Check for null as it may be set to null if the channel is closed already                 if (buffer != null) {                     buffer.incrementPendingOutboundBytes(size);                 }             }             safeExecuteOutbound(WriteTask.newInstance(ctx, msg, size, promise), promise, msg);         }     }

通过上述代码可以看出，Netty首先对当前的操作的线程进行判断，如果操作本身就是由NioEventLoop线程执行，则调用写操作；否则，执行线程安全的写操作，即将写事件封装成Task，放入到任务队列中由Netty的I/O线程执行，业务调用返回，流程继续执行。

通过源码分析，问题根源已经很清楚：系统升级到Netty 4之后，线程模型发生变化，响应消息的编码由NioEventLoop线程异步执行，业务线程返回。这时存在两种可能：

1. 如果编码操作先于修改应答消息的业务逻辑执行，则运行结果正确；
2. 如果编码操作在修改应答消息的业务逻辑之后执行，则运行结果错误。

由于线程的执行先后顺序无法预测，因此该问题隐藏的相当深。如果对Netty 4和Netty3的线程模型不了解，就会掉入陷阱。

Netty 3版本业务逻辑没有问题，流程如下：

图3-1 升级之前的业务流程线程模型

升级到Netty 4版本之后，业务流程由于Netty线程模型的变更而发生改变，导致业务逻辑发生问题：

图3-2 升级之后的业务处理流程发生改变

3.3. 问题总结

很多读者在进行Netty 版本升级的时候，只关注到了包路径、类和API的变更，并没有注意到隐藏在背后的“暗箭”- 线程模型变更。

升级到Netty 4的用户需要根据新的线程模型对已有的系统进行评估，重点需要关注outbound的ChannelHandler，如果它的正确性依赖于Netty 3的线程模型，则很可能在新的线程模型中出问题，可能是功能问题或者其它问题。

4. Netty升级之后性能严重下降

4.1. 问题描述

相信很多Netty用户都看过如下相关报告：

在Twitter，Netty 4 GC开销降为五分之一：Netty 3使用Java对象表示I/O事件，这样简单，但会产生大量的垃圾，尤其是在我们这样的规模下。Netty 4在新版本中对此做出了更改，取代生存周期短的事件对象，而以定义在生存周期长的通道对象上的方法处理I/O事件。它还有一个使用池的专用缓冲区分配器。

每当收到新信息或者用户发送信息到远程端，Netty 3均会创建一个新的堆缓冲区。这意味着，对应每一个新的缓冲区，都会有一个‘new byte[capacity]’。这些缓冲区会导致GC压力，并消耗内存带宽：为了安全起见，新的字节数组分配时会用零填充，这会消耗内存带宽。然而，用零填充的数组很可能会再次用实际的数据填充，这又会消耗同样的内存带宽。如果Java虚拟机（JVM）提供了创建新字节数组而又无需用零填充的方式，那么我们本来就可以将内存带宽消耗减少50%，但是目前没有那样一种方式。

在Netty 4中，代码定义了粒度更细的API，用来处理不同的事件类型，而不是创建事件对象。它还实现了一个新缓冲池，那是一个纯Java版本的 jemalloc （Facebook也在用）。现在，Netty不会再因为用零填充缓冲区而浪费内存带宽了。

我们比较了两个分别建立在Netty 3和4基础上echo协议服务器。（Echo非常简单，这样，任何垃圾的产生都是Netty的原因，而不是协议的原因）。我使它们服务于相同的分布式echo协议客户端，来自这些客户端的16384个并发连接重复发送256字节的随机负载，几乎使千兆以太网饱和。

根据测试结果，Netty 4：

• GC中断频率是原来的1/5： 45.5 vs. 9.2次/分钟
• 垃圾生成速度是原来的1/5： 207.11 vs 41.81 MiB/秒

正是看到了相关的Netty 4性能提升报告，很多用户选择了升级。事后一些用户反馈Netty 4并没有跟产品带来预期的性能提升，有些甚至还发生了非常严重的性能下降，下面我们就以某业务产品的失败升级经历为案例，详细分析下导致性能下降的原因。

4.2. 问题定位

首先通过JMC等性能分析工具对性能热点进行分析，示例如下（信息安全等原因，只给出分析过程示例截图）：

图4-1 JMC性能监控分析

通过对热点方法的分析，发现在消息发送过程中，有两处热点：

1. 消息发送性能统计相关Handler;
2. 编码Handler。

对使用Netty 3版本的业务产品进行性能对比测试，发现上述两个Handler也是热点方法。既然都是热点，为啥切换到Netty4之后性能下降这么厉害呢？

通过方法的调用树分析发现了两个版本的差异：在Netty 3中，上述两个热点方法都是由业务线程负责执行；而在Netty 4中，则是由NioEventLoop(I/O)线程执行。对于某个链路，业务是拥有多个线程的线程池，而NioEventLoop只有一个，所以执行效率更低，返回给客户端的应答时延就大。时延增大之后，自然导致系统并发量降低，性能下降。

找出问题根因之后，针对Netty 4的线程模型对业务进行专项优化，性能达到预期，远超过了Netty 3老版本的性能。

Netty 3的业务线程调度模型图如下所示：充分利用了业务多线程并行编码和Handler处理的优势，周期T内可以处理N条业务消息。

图4-2 Netty 3业务调度性能模型

切换到Netty 4之后，业务耗时Handler被I/O线程串行执行，因此性能发生比较大的下降：

图4-3 Netty 4业务调度性能模型

4.3. 问题总结

该问题的根因还是由于Netty 4的线程模型变更引起，线程模型变更之后，不仅影响业务的功能，甚至对性能也会造成很大的影响。

对Netty的升级需要从功能、兼容性和性能等多个角度进行综合考虑，切不可只盯着API变更这个芝麻，而丢掉了性能这个西瓜。API的变更会导致编译错误，但是性能下降却隐藏于无形之中，稍不留意就会中招。

对于讲究快速交付、敏捷开发和灰度发布的互联网应用，升级的时候更应该要当心。

5. Netty升级之后上下文丢失

5.1. 问题描述

为了提升业务的二次定制能力，降低对接口的侵入性，业务使用线程变量进行消息上下文的传递。例如消息发送源地址信息、消息Id、会话Id等。

业务同时使用到了一些第三方开源容器，也提供了线程级变量上下文的能力。业务通过容器上下文获取第三方容器的系统变量信息。

升级到Netty 4之后，业务继承自Netty的ChannelHandler发生了空指针异常，无论是业务自定义的线程上下文、还是第三方容器的线程上下文，都获取不到传递的变量值。

5.2. 问题定位

首先检查代码，看业务是否传递了相关变量，确认业务传递之后怀疑跟Netty 版本升级相关，调试发现，业务ChannelHandler获取的线程上下文对象和之前业务传递的上下文不是同一个。这就说明执行ChannelHandler的线程跟处理业务的线程不是同一个线程！

查看Netty 4线程模型的相关Doc发现，Netty修改了outbound的线程模型，正好影响了业务消息发送时的线程上下文传递，最终导致线程变量丢失。

5.3. 问题总结

通常业务的线程模型有如下几种：

1. 业务自定义线程池/线程组处理业务，例如使用JDK 1.5提供的ExecutorService；
2. 使用J2EE Web容器自带的线程模型，常见的如JBoss和Tomcat的HTTP接入线程等；
3. 隐式的使用其它第三方框架的线程模型，例如使用NIO框架进行协议处理，业务代码隐式使用的就是NIO框架的线程模型，除非业务明确的实现自定义线程模型。

在实践中我们发现很多业务使用了第三方框架，但是只熟悉API和功能，对线程模型并不清楚。某个类库由哪个线程调用，糊里糊涂。为了方便变量传递，又随意的使用线程变量，实际对背后第三方类库的线程模型产生了强依赖。当容器或者第三方类库升级之后，如果线程模型发生了变更，则原有功能就会发生问题。

鉴于此，在实际工作中，尽量不要强依赖第三方类库的线程模型，如果确实无法避免，则必须对它的线程模型有深入和清晰的了解。当第三方类库升级之后，需要检查线程模型是否发生变更，如果发生变化，相关的代码也需要考虑同步升级。

6. Netty3.X VS Netty4.X 之线程模型

通过对三个具有典型性的升级失败案例进行分析和总结，我们发现有个共性：都是线程模型改变惹的祸!

下面小节我们就详细得对Netty3和Netty4版本的I/O线程模型进行对比，以方便大家掌握两者的差异，在升级和使用中尽量少踩雷。

6.1 Netty 3.X 版本线程模型

Netty 3.X的I/O操作线程模型比较复杂，它的处理模型包括两部分：

1. Inbound：主要包括链路建立事件、链路激活事件、读事件、I/O异常事件、链路关闭事件等；
2. Outbound：主要包括写事件、连接事件、监听绑定事件、刷新事件等。

我们首先分析下Inbound操作的线程模型：

图6-1 Netty 3 Inbound操作线程模型

从上图可以看出，Inbound操作的主要处理流程如下：

1. I/O线程（Work线程）将消息从TCP缓冲区读取到SocketChannel的接收缓冲区中；
2. 由I/O线程负责生成相应的事件，触发事件向上执行，调度到ChannelPipeline中；
3. I/O线程调度执行ChannelPipeline中Handler链的对应方法，直到业务实现的Last Handler;
4. Last Handler将消息封装成Runnable，放入到业务线程池中执行，I/O线程返回，继续读/写等I/O操作；
5. 业务线程池从任务队列中弹出消息，并发执行业务逻辑。

通过对Netty 3的Inbound操作进行分析我们可以看出，Inbound的Handler都是由Netty的I/O Work线程负责执行。

下面我们继续分析Outbound操作的线程模型：

图6-2 Netty 3 Outbound操作线程模型

从上图可以看出，Outbound操作的主要处理流程如下：

业务线程发起Channel Write操作，发送消息；

1. Netty将写操作封装成写事件，触发事件向下传播；
2. 写事件被调度到ChannelPipeline中，由业务线程按照Handler Chain串行调用支持Downstream事件的Channel Handler;
3. 执行到系统最后一个ChannelHandler，将编码后的消息Push到发送队列中，业务线程返回；
4. Netty的I/O线程从发送消息队列中取出消息，调用SocketChannel的write方法进行消息发送。

6.2 Netty 4.X 版本线程模型

相比于Netty 3.X系列版本，Netty 4.X的I/O操作线程模型比较简答，它的原理图如下所示：

图6-3 Netty 4 Inbound和Outbound操作线程模型

从上图可以看出，Outbound操作的主要处理流程如下：

1. I/O线程NioEventLoop从SocketChannel中读取数据报，将ByteBuf投递到ChannelPipeline，触发ChannelRead事件；
2. I/O线程NioEventLoop调用ChannelHandler链，直到将消息投递到业务线程，然后I/O线程返回，继续后续的读写操作；
3. 业务线程调用ChannelHandlerContext.write(Object msg)方法进行消息发送；
4. 如果是由业务线程发起的写操作，ChannelHandlerInvoker将发送消息封装成Task，放入到I/O线程NioEventLoop的任务队列中，由NioEventLoop在循环中统一调度和执行。放入任务队列之后，业务线程返回；
5. I/O线程NioEventLoop调用ChannelHandler链，进行消息发送，处理Outbound事件，直到将消息放入发送队列，然后唤醒Selector，进而执行写操作。

通过流程分析，我们发现Netty 4修改了线程模型，无论是Inbound还是Outbound操作，统一由I/O线程NioEventLoop调度执行。

6.3. 线程模型对比

在进行新老版本线程模型PK之前，首先还是要熟悉下串行化设计的理念：

我们知道当系统在运行过程中，如果频繁的进行线程上下文切换，会带来额外的性能损耗。多线程并发执行某个业务流程，业务开发者还需要时刻对线程安全保持警惕，哪些数据可能会被并发修改，如何保护？这不仅降低了开发效率，也会带来额外的性能损耗。

为了解决上述问题，Netty 4采用了串行化设计理念，从消息的读取、编码以及后续Handler的执行，始终都由I/O线程NioEventLoop负责，这就意外着整个流程不会进行线程上下文的切换，数据也不会面临被并发修改的风险，对于用户而言，甚至不需要了解Netty的线程细节，这确实是个非常好的设计理念，它的工作原理图如下：

图6-4 Netty 4的串行化设计理念

一个NioEventLoop聚合了一个多路复用器Selector，因此可以处理成百上千的客户端连接，Netty的处理策略是每当有一个新的客户端接入，则从NioEventLoop线程组中顺序获取一个可用的NioEventLoop，当到达数组上限之后，重新返回到0，通过这种方式，可以基本保证各个NioEventLoop的负载均衡。一个客户端连接只注册到一个NioEventLoop上，这样就避免了多个I/O线程去并发操作它。

Netty通过串行化设计理念降低了用户的开发难度，提升了处理性能。利用线程组实现了多个串行化线程水平并行执行，线程之间并没有交集，这样既可以充分利用多核提升并行处理能力，同时避免了线程上下文的切换和并发保护带来的额外性能损耗。

了解完了Netty 4的串行化设计理念之后，我们继续看Netty 3线程模型存在的问题，总结起来，它的主要问题如下：

1. Inbound和Outbound实质都是I/O相关的操作，它们的线程模型竟然不统一，这给用户带来了更多的学习和使用成本；
2. Outbound操作由业务线程执行，通常业务会使用线程池并行处理业务消息，这就意味着在某一个时刻会有多个业务线程同时操作ChannelHandler，我们需要对ChannelHandler进行并发保护，通常需要加锁。如果同步块的范围不当，可能会导致严重的性能瓶颈，这对开发者的技能要求非常高，降低了开发效率；
3. Outbound操作过程中，例如消息编码异常，会产生Exception，它会被转换成Inbound的Exception并通知到ChannelPipeline，这就意味着业务线程发起了Inbound操作！它打破了Inbound操作由I/O线程操作的模型，如果开发者按照Inbound操作只会由一个I/O线程执行的约束进行设计，则会发生线程并发访问安全问题。由于该场景只在特定异常时发生，因此错误非常隐蔽！一旦在生产环境中发生此类线程并发问题，定位难度和成本都非常大。

讲了这么多，似乎Netty 4 完胜 Netty 3的线程模型，其实并不尽然。在特定的场景下，Netty 3的性能可能更高，就如本文第4章节所讲，如果编码和其它Outbound操作非常耗时，由多个业务线程并发执行，性能肯定高于单个NioEventLoop线程。

但是，这种性能优势不是不可逆转的，如果我们修改业务代码，将耗时的Handler操作前置，Outbound操作不做复杂业务逻辑处理，性能同样不输于Netty 3，但是考虑内存池优化、不会反复创建Event、不需要对Handler加锁等Netty 4的优化，整体性能Netty 4版本肯定会更高。

总而言之，如果用户真正熟悉并掌握了Netty 4的线程模型和功能类库，相信不仅仅开发会更加简单，性能也会更优！

6.4. 思考

就Netty 而言，掌握线程模型的重要性不亚于熟悉它的API和功能。很多时候我遇到的功能、性能等问题，都是由于缺乏对它线程模型和原理的理解导致的，结果我们就以讹传讹，认为Netty 4版本不如3好用等。

不能说所有开源软件的版本升级一定都胜过老版本，就Netty而言，我认为Netty 4版本相比于老的Netty 3，确实是历史的一大进步。

7. 作者简介

李林锋，2007年毕业于东北大学，2008年进入华为公司从事高性能通信软件的设计和开发工作，有7年NIO设计和开发经验，精通Netty、Mina等NIO框架和平台中间件，现任华为软件平台架构部架构师，《Netty权威指南》作者。

联系方式：新浪微博 Nettying 微信：Nettying 微信公众号：Netty之家

感谢郭蕾对本文的策划和审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

接近一周没更新《Java线程》专栏了，主要是这周工作上比较忙，生活上也比较忙，呵呵，进入正题，上一篇讲述了并发包下的Lock，Lock可以更好的解决线程同步问题，使之更面向对象，并且ReadWriteLock在处理同步时更强大，那么同样，线程间仅仅互斥是不够的，还需要通信，本篇的内容是基于上篇之上，使用Lock如何处理线程通信。

        那么引入本篇的主角，Condition，Condition 将 Object 监视器方法（wait、notify 和 notifyAll）分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set （wait-set）。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。下面将之前写过的一个线程通信的例子替换成用Condition实现(Java线程(三))，代码如下：

[java] view plaincopyprint?

1. public class ThreadTest2 {  
2.     public static void main(String[] args) {  
3.         final Business business = new Business();  
4.         new Thread(new Runnable() {  
5.             @Override  
6.             public void run() {  
7.                 threadExecute(business, "sub");  
8.             }  
9.         }).start();  
10.         threadExecute(business, "main");  
11.     }     
12.     public static void threadExecute(Business business, String threadType) {  
13.         for(int i = 0; i < 100; i++) {  
14.             try {  
15.                 if("main".equals(threadType)) {  
16.                     business.main(i);  
17.                 } else {  
18.                     business.sub(i);  
19.                 }  
20.             } catch (InterruptedException e) {  
21.                 e.printStackTrace();  
22.             }  
23.         }  
24.     }  
25. }  
26. class Business {  
27.     private boolean bool = true;  
28.     private Lock lock = new ReentrantLock();  
29.     private Condition condition = lock.newCondition();   
30.     public /*synchronized*/ void main(int loop) throws InterruptedException {  
31.         lock.lock();  
32.         try {  
33.             while(bool) {                 
34.                 condition.await();//this.wait();  
35.             }  
36.             for(int i = 0; i < 100; i++) {  
37.                 System.out.println("main thread seq of " + i + ", loop of " + loop);  
38.             }  
39.             bool = true;  
40.             condition.signal();//this.notify();  
41.         } finally {  
42.             lock.unlock();  
43.         }  
44.     }     
45.     public /*synchronized*/ void sub(int loop) throws InterruptedException {  
46.         lock.lock();  
47.         try {  
48.             while(!bool) {  
49.                 condition.await();//this.wait();  
50.             }  
51.             for(int i = 0; i < 10; i++) {  
52.                 System.out.println("sub thread seq of " + i + ", loop of " + loop);  
53.             }  
54.             bool = false;  
55.             condition.signal();//this.notify();  
56.         } finally {  
57.             lock.unlock();  
58.         }  
59.     }  
60. }  

        这样看来，Condition和传统的线程通信没什么区别，Condition的强大之处在于它可以为多个线程间建立不同的Condition，下面引入API中的一段代码，加以说明。

[java] view plaincopyprint?

1. class BoundedBuffer {  
2.    final Lock lock = new ReentrantLock();//锁对象  
3.    final Condition notFull  = lock.newCondition();//写线程条件   
4.    final Condition notEmpty = lock.newCondition();//读线程条件   
5.   
6.    final Object[] items = new Object[100];//缓存队列  
7.    int putptr/*写索引*/, takeptr/*读索引*/, count/*队列中存在的数据个数*/;  
8.   
9.    public void put(Object x) throws InterruptedException {  
10.      lock.lock();  
11.      try {  
12.        while (count == items.length)//如果队列满了   
13.          notFull.await();//阻塞写线程  
14.        items[putptr] = x;//赋值   
15.        if (++putptr == items.length) putptr = 0;//如果写索引写到队列的最后一个位置了，那么置为0  
16.        ++count;//个数++  
17.        notEmpty.signal();//唤醒读线程  
18.      } finally {  
19.        lock.unlock();  
20.      }  
21.    }  
22.   
23.    public Object take() throws InterruptedException {  
24.      lock.lock();  
25.      try {  
26.        while (count == 0)//如果队列为空  
27.          notEmpty.await();//阻塞读线程  
28.        Object x = items[takeptr];//取值   
29.        if (++takeptr == items.length) takeptr = 0;//如果读索引读到队列的最后一个位置了，那么置为0  
30.        --count;//个数--  
31.        notFull.signal();//唤醒写线程  
32.        return x;  
33.      } finally {  
34.        lock.unlock();  
35.      }  
36.    }   
37.  }  

        1. 一个写线程执行，调用put方法；

        2. 判断count是否为100，显然没有100；

        3. 继续执行，存入值；

        4. 判断当前写入的索引位置++后，是否和100相等，相等将写入索引值变为0，并将count+1；

        5. 仅唤醒读线程阻塞队列中的一个；

        6. 一个读线程执行，调用take方法；

        7. ……

        8. 仅唤醒写线程阻塞队列中的一个。

        这就是多个Condition的强大之处，假设缓存队列中已经存满，那么阻塞的肯定是写线程，唤醒的肯定是读线程，相反，阻塞的肯定是读线程，唤醒的肯定是写线程，那么假设只有一个Condition会有什么效果呢，缓存队列中已经存满，这个Lock不知道唤醒的是读线程还是写线程了，如果唤醒的是读线程，皆大欢喜，如果唤醒的是写线程，那么线程刚被唤醒，又被阻塞了，这时又去唤醒，这样就浪费了很多时间。

        本文来自：高爽|Coder，原文地址：http://blog.csdn.net/ghsau/article/details/7481142，转载请注明。

一、概述：

      在Redis中，我们可以将Set类型看作为没有排序的字符集合，和List类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为O(1)，即常量时间内完成次操作。Set可包含的最大元素数量是4294967295。
      和List类型不同的是，Set集合中不允许出现重复的元素，这一点和C++标准库中的set容器是完全相同的。换句话说，如果多次添加相同元素，Set中将仅保留该元素的一份拷贝。和List类型相比，Set类型在功能上还存在着一个非常重要的特性，即在服务器端完成多个Sets之间的聚合计算操作，如unions、intersections和differences。由于这些操作均在服务端完成，因此效率极高，而且也节省了大量的网络IO开销。

二、相关命令列表：

三、命令示例：

   1. SADD/SMEMBERS/SCARD/SISMEMBER:
    #在Shell命令行下启动Redis的客户端程序。
    /> redis-cli
    #插入测试数据，由于该键myset之前并不存在，因此参数中的三个成员都被正常插入。
    redis 127.0.0.1:6379> sadd myset a b c
    (integer) 3
    #由于参数中的a在myset中已经存在，因此本次操作仅仅插入了d和e两个新成员。
    redis 127.0.0.1:6379> sadd myset a d e
    (integer) 2
    #判断a是否已经存在，返回值为1表示存在。
    redis 127.0.0.1:6379> sismember myset a
    (integer) 1
    #判断f是否已经存在，返回值为0表示不存在。
    redis 127.0.0.1:6379> sismember myset f
    (integer) 0
    #通过smembers命令查看插入的结果，从结果可以，输出的顺序和插入顺序无关。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    5) "e"
    #获取Set集合中元素的数量。
    redis 127.0.0.1:6379> scard myset
    (integer) 5

    2. SPOP/SREM/SRANDMEMBER/SMOVE:
    #删除该键，便于后面的测试。
    redis 127.0.0.1:6379> del myset
    (integer) 1
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    #查看Set中成员的位置。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    #从结果可以看出，该命令确实是随机的返回了某一成员。
    redis 127.0.0.1:6379> srandmember myset
    "c"
    #Set中尾部的成员b被移出并返回，事实上b并不是之前插入的第一个或最后一个成员。
    redis 127.0.0.1:6379> spop myset
    "b"
    #查看移出后Set的成员信息。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    #从Set中移出a、d和f三个成员，其中f并不存在，因此只有a和d两个成员被移出，返回为2。
    redis 127.0.0.1:6379> srem myset a d f
    (integer) 2
    #查看移出后的输出结果。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    #为后面的smove命令准备数据。
    redis 127.0.0.1:6379> sadd myset a b
    (integer) 2
    redis 127.0.0.1:6379> sadd myset2 c d
    (integer) 2
    #将a从myset移到myset2，从结果可以看出移动成功。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 1
    #再次将a从myset移到myset2，由于此时a已经不是myset的成员了，因此移动失败并返回0。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 0
    #分别查看myset和myset2的成员，确认移动是否真的成功。
    redis 127.0.0.1:6379> smembers myset
    1) "b"
    redis 127.0.0.1:6379> smembers myset2
    1) "c"
    2) "d"
    3) "a"

   3. SDIFF/SDIFFSTORE/SINTER/SINTERSTORE:
    #为后面的命令准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    redis 127.0.0.1:6379> sadd myset2 c
    (integer) 1
    redis 127.0.0.1:6379> sadd myset3 a c e
    (integer) 3
    #myset和myset2相比，a、b和d三个成员是两者之间的差异成员。再用这个结果继续和myset3进行差异比较，b和d是myset3不存在的成员。
    redis 127.0.0.1:6379> sdiff myset myset2 myset3
    1) "d"
    2) "b"
    #将3个集合的差异成员存在在diffkey关联的Set中，并返回插入的成员数量。
    redis 127.0.0.1:6379> sdiffstore diffkey myset myset2 myset3
    (integer) 2
    #查看一下sdiffstore的操作结果。
    redis 127.0.0.1:6379> smembers diffkey
    1) "d"
    2) "b"
    #从之前准备的数据就可以看出，这三个Set的成员交集只有c。
    redis 127.0.0.1:6379> sinter myset myset2 myset3
    1) "c"
    #将3个集合中的交集成员存储到与interkey关联的Set中，并返回交集成员的数量。
    redis 127.0.0.1:6379> sinterstore interkey myset myset2 myset3
    (integer) 1
    #查看一下sinterstore的操作结果。
    redis 127.0.0.1:6379> smembers interkey
    1) "c"
    #获取3个集合中的成员的并集。    
    redis 127.0.0.1:6379> sunion myset myset2 myset3
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"
    #将3个集合中成员的并集存储到unionkey关联的set中，并返回并集成员的数量。
    redis 127.0.0.1:6379> sunionstore unionkey myset myset2 myset3
    (integer) 5
    #查看一下suiionstore的操作结果。
    redis 127.0.0.1:6379> smembers unionkey
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"

四、应用范围：

      1). 可以使用Redis的Set数据类型跟踪一些唯一性数据，比如访问某一博客的唯一IP地址信息。对于此场景，我们仅需在每次访问该博客时将访问者的IP存入Redis中，Set数据类型会自动保证IP地址的唯一性。
      2). 充分利用Set类型的服务端聚合操作方便、高效的特性，可以用于维护数据对象之间的关联关系。比如所有购买某一电子设备的客户ID被存储在一个指定的Set中，而购买另外一种电子产品的客户ID被存储在另外一个Set中，如果此时我们想获取有哪些客户同时购买了这两种商品时，Set的intersections命令就可以充分发挥它的方便和效率的优势了。

一、概述：

      我们可以将Redis中的Hashes类型看成具有String Key和String Value的map容器。所以该类型非常适合于存储值对象的信息。如Username、Password和Age等。如果Hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个Hash可以存储4294967295个键值对。

二、相关命令列表：

三、命令示例：

    1. HSET/HGET/HDEL/HEXISTS/HLEN/HSETNX:
    #在Shell命令行启动Redis客户端程序
    /> redis-cli
    #给键值为myhash的键设置字段为field1，值为stephen。
    redis 127.0.0.1:6379> hset myhash field1 "stephen"
    (integer) 1
    #获取键值为myhash，字段为field1的值。
    redis 127.0.0.1:6379> hget myhash field1
    "stephen"
    #myhash键中不存在field2字段，因此返回nil。
    redis 127.0.0.1:6379> hget myhash field2
    (nil)
    #给myhash关联的Hashes值添加一个新的字段field2，其值为liu。
    redis 127.0.0.1:6379> hset myhash field2 "liu"
    (integer) 1
    #获取myhash键的字段数量。
    redis 127.0.0.1:6379> hlen myhash
    (integer) 2
    #判断myhash键中是否存在字段名为field1的字段，由于存在，返回值为1。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 1
    #删除myhash键中字段名为field1的字段，删除成功返回1。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 1
    #再次删除myhash键中字段名为field1的字段，由于上一条命令已经将其删除，因为没有删除，返回0。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 0
    #判断myhash键中是否存在field1字段，由于上一条命令已经将其删除，因为返回0。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 0
    #通过hsetnx命令给myhash添加新字段field1，其值为stephen，因为该字段已经被删除，所以该命令添加成功并返回1。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 1
    #由于myhash的field1字段已经通过上一条命令添加成功，因为本条命令不做任何操作后返回0。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 0

   2. HINCRBY：
    #删除该键，便于后面示例的测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #准备测试数据，该myhash的field字段设定值1。
    redis 127.0.0.1:6379> hset myhash field 5
    (integer) 1
    #给myhash的field字段的值加1，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field 1
    (integer) 6
    #给myhash的field字段的值加-1，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -1
    (integer) 5
    #给myhash的field字段的值加-10，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -10
    (integer) -5   

    3. HGETALL/HKEYS/HVALS/HMGET/HMSET:
    #删除该键，便于后面示例测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #为该键myhash，一次性设置多个字段，分别是field1 = "hello", field2 = "world"。
    redis 127.0.0.1:6379> hmset myhash field1 "hello" field2 "world"
    OK
    #获取myhash键的多个字段，其中field3并不存在，因为在返回结果中与该字段对应的值为nil。
    redis 127.0.0.1:6379> hmget myhash field1 field2 field3
    1) "hello"
    2) "world"
    3) (nil)
    #返回myhash键的所有字段及其值，从结果中可以看出，他们是逐对列出的。
    redis 127.0.0.1:6379> hgetall myhash
    1) "field1"
    2) "hello"
    3) "field2"
    4) "world"
    #仅获取myhash键中所有字段的名字。
    redis 127.0.0.1:6379> hkeys myhash
    1) "field1"
    2) "field2"
    #仅获取myhash键中所有字段的值。
    redis 127.0.0.1:6379> hvals myhash
    1) "hello"
    2) "world"