本文总结分享网络编程中涉及的长连接、短连接概念。

一、什么是长连接

HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。

HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0 代理不理解Keep-alive，而导致长连接失效：客户端–>代理–>服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端–>代理”连接和“代理–>服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多，很多时候代理是我们自己控制的，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理，常见的是客户端跟Nginx代理服务器使用HTTP1.1协议&长连接，而Nginx代理服务器跟后端服务器使用HTTP1.0协议&短连接。

在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection: Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。

以前使用libcurl做的上传/下载，就是短连接，抓包可以看到：1、每一条TCP通道只有一个POST；2、在数据传输完毕可以看到四次握手包。只要不调用curl_easy_cleanup，curl的handle就可能一直有效，可复用。这里说可能，因为连接是双方的，如果服务器那边关掉了，那么我客户端这边保留着也不能实现长连接。

如果是使用windows的WinHTTP库，则在POST/GET数据的时候，虽然我关闭了句柄，但这时候TCP连接并不会立即关闭，而是等一小会儿，这时候是WinHTTP库底层支持了跟Keep-alive所需要的功能：即便没有Keep-alive，WinHTTP库也可能会加上这种TCP通道复用的功能，而其它的网络库像libcurl则不会这么做。以前观察过 WinHTTP库不会及时断开TCP连接。

二、长连接的过期时间

客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：

上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。

三、长连接的数据传输完成识别

使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。更细节的介绍可以看 这篇文章。

四、并发连接数的数量限制

在web开发中需要关注浏览器并发连接的数量， RFC文档说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩， 知乎这里有分析，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。

五、容易混淆的概念—— TCP的keep alive和HTTP的Keep-alive

TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。

TCP keep alive的表现：

当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。

这个“一段时间”可以设置。

WinHttp库的设置：

WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.

libcurl的设置：

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html

CURLOPT_TCP_KEEPALIVE

Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).

CURLOPT_TCP_KEEPIDLE

Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT_TCP_KEEPINTVL

Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option. (Added in 7.25.0)

CURLOPT_TCP_KEEPIDLE是空闲多久发送一个心跳包，CURLOPT_TCP_KEEPINTVL是心跳包间隔多久发一个。

打开网页抓包，发送心跳包和关闭连接如下：

从上图可以看到，大概过了44秒，客户端发出了心跳包，服务器及时回应，本TCP连接继续保持。到了空闲60秒的时候，服务器主动发起FIN包，断开连接。

六、HTTP 流水线技术

使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指， 在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining。

由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决）。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样。

在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源。

目前浏览器并不太重视这个技术，毕竟性能提升有限。

七、学习资料

• 1、HTTP Keep-Alive模式： http://www.cnblogs.com/skynet/archive/2010/12/11/1903347.html
• 2、浏览器的并发请求限制： http://www.zhihu.com/question/20474326
• 3、RFC文档 connection部分：http://tools.ietf.org/html/rfc2616#page-44
• 4、C/C++网络编程中的TCP保活：  http://blog.csdn.net/weiwangchao_/article/details/7225338
• 5、HTTP persistent connection： http://en.wikipedia.org/wiki/HTTP_persistent_connection
• 6、HTTP pipelining：http://en.wikipedia.org/wiki/HTTP_pipelining
• 7、Head-of-line blocking：http://en.wikipedia.org/wiki/Head-of-line_blocking
• 8、《HTTP权威指南》第四章 连接管理

HTTP 的长连接和短连接，首发于 文章 - 伯乐在线。

在《 这多年来我一直在钻研的技术》这篇文章中，我讲述了一下，我这么多年来一直在关注的技术领域，其中我多次提到了工业级的软件，我还以为有很多人会问我怎么定义工业级？以及一个高可用性的软件系统应该要怎么干出来？这样我也可以顺理成章的写下这篇文章，但是没有人问，那么，我只好厚颜无耻的自己写下这篇文章了。哈哈。

另外，我在一些讨论高可用系统的地方看到大家只讨论各个公司的技术方案， 其实，高可用的系统并不简单的是技术方案，一个高可用的系统其实还包括很多别的东西，所以，我觉得大家对高可用的系统了解的还不全面，为了让大家的认识更全面，所以，我写下这篇文章。

理解高可用系统

首先，我们需要理解什么是高可用，英文叫High Availability（ Wikipedia词条），基本上来说，就是要让我们的计算环境（包括软硬件）做到full-time的可用性。在设计上一般来说，需要做好如下的设计：

1. 对软硬件的冗余，以消除单点故障。任何系统都会有一个或多个冗余系统做standby
2. 对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover
3. 需要很可靠的交汇点（CrossOver）。这是一些不容易冗余的结点，比如域名解析，负载均衡器等。

听起似乎很简单吧，然而不是，细节之处全是魔鬼，冗余结点最大的难题就是对于有状态的结点的数据复制和数据一致性的保证（无状态结点的冗余相对比较简单）。冗余数据所带来的一致性问题是魔鬼中的魔鬼：

• 如果系统的数据镜像到冗余结点是异步的，那么在failover的时候就会出现数据差异的情况。

• 如果系统在数据镜像到冗余结点是同步的，那么就会导致冗余结点越多性能越慢。

所以，很多高可用系统都是在做各种取舍，这需要比对着业务的特点来的，比如银行账号的余额是一个状态型的数据，那么，冗余时就必需做到强一致性，再比如说，订单记录属于追加性的数据，那么在failover的时候，就可以到备机上进行追加，这样就比较简单了（阿里目前所谓的异地双活其实根本做不到状态型数据的双活）。

下面，总结一下高可用的设计原理：

• 要做到数据不丢，就必需要持久化
• 要做到服务高可用，就必需要有备用（复本），无论是应用结点还是数据结点
• 要做到复制，就会有数据一致性的问题。
• 我们不可能做到100%的高可用，也就是说，我们能做到几个9个的SLA。

高可用系统的技术解决方案

我在《 分布式系统的事务处理》中引用过下面这个图：这个图来自来自：Google App Engine的co-founder Ryan Barrett在2009年的Google I/O上的演讲《 Transaction Across DataCenter》（视频：  http://www.youtube.com/watch?v=srOgpXECblk）

这个图基本上来说是目前高可用系统中能看得到的所有的解决方案的基础了。M/S、MM实现起来不难，但是会有很多问题，2PC的问题就是性能不行，而Paxos的问题就是太复杂，实现难度太大。

总结一下各个高可用方案的的问题：

• 对于最终一致性来说，在宕机的情况下，会出现数据没有完全同步完成，会出现数据差异性。
• 对于强一致性来说，要么使用性能比较慢的 XA系的两阶段提交的方案，要么使用性能比较好，但是实现比较复杂的Paxos协议。

注：这是软件方面的方案。当然，也可以使用造价比较高的硬件解决方案，不过本文不涉及硬件解决方案。

另外，现今开源软件中，很多缓存，消息中间件或数据库都有持久化和Replication的设计，从而也都有高可用解决方案，但是开源软件一般都没有比较高的SLA，所以，如果我们使用开源软件的话，需要注意这一点。

高可用技术方案的示例

下面，我们来看一下MySQL的高可用的方案的SLA（下图下面红色的标识表示了这个方案有几个9）：

图片来源： MySQL High Availability Solutions

简单解释一下MySQL的这几个方案（主要是想表达一个越多的9就越复杂）

• MySQL Repleaction就是传统的异步数据同步或是半同步Semi-Sync（只要有一个slave收到更新就返回成功）这个方式本质上不到2个9。
• MySQL Fabric简单来说就是数据分片下的M/S的读写分离模式。这个方案的的可用性可以达到99%
• DRBD通过底层的磁盘同步技术来解决数据同步的问题，就是RAID 1——把两台以上的主机的硬盘镜像成一个。这个方案不到3个9
• Solaris Clustering/Oracle VM ，这个机制监控了包括硬件、操作系统、网络和数据库。这个方案一般会伴随着节点间的“心跳机制”，而且还会动用到SAN（Storage Area Network）或是本地的分布式存储系统，还会动用虚拟化技术来做虚拟机的迁移以降低宕机时间的概率。这个解决方案完全就是一个“全栈式的解决方案”。这个方案接近4个9。
• MySQL Cluster是官方的一个开源方案，其把MySQL的集群分成SQL Node 和Data Node，Data Node是一个自动化sharing和复制的集群NDB，为了更高的可用性，MySQL Cluster采用了“完全同步”的数据复制的机制来冗余数据结点。这个方案接近5个9。

那么，这些2个9，3个9，4个9，5个9是什么意思呢？又是怎么来的呢？请往下看。

高可用性的SLA的定义

上面那些都不是本文的重点，本文的重点现在开始，如何测量系统的高可用性。当然是SLA，全称 Service Level Agrement，也就是有几个9的高可用性。

工业界有两种方法来测量SLA，

• 一个是故障发生到恢复的时间
• 另一个是两次故障间的时间

但大多数都采用第一种方法，也就是故障发生到恢复的时间，也就是服务不可用的时间，如下表所示：

比如，99.999%的可用性，一年只能有5分半钟的服务不可用。感觉很难做到吧。

就算是3个9的可用性，一个月的宕机时间也只有40多分钟，看看那些设计和编码不认真的团队，把所有的期望寄托在人肉处理故障的运维团队， 一个故障就能处理1个多小时甚至2-3个小时，连个自动化的工具都没有，还好意思在官网上声明自己的SLA是3个9或是5个9，这不是欺骗大众吗？。

影响高可用的因素

老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有每三方的服务（如电信联通的宽带SLA），当然包括“建筑施工队的挖掘机”。所以，正如SLA的定义， 这不仅仅只是一个技术指标，而是一种服务提供商和用户之间的contract或契约。 这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。

简而言之，SLA的几个9就是能持续提供可用服务的级别，不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。

无计划的宕机原因

下图来自Oracle的 《 High Availability Concepts and Best Practices》

有计划的宕机原因

下图来自Oracle的 《 High Availability Concepts and Best Practices》

我们可以看到，上面的宕机原因包括如下：

无计划的

• 系统级的故障 –  包括主机、操作系统、中间件、数据库、网络、电源以及外围设备
• 数据和中介的故障 – 包括人员误操作、硬盘故障、数据乱了
• 还有：自然灾害、人为破坏、以及供电问题。

有计划的

• 日常任务：备份，容量规划，用户和安全管理，后台批处理应用
• 运维相关：数据库维护、应用维护、中间件维护、操作系统维护、网络维护
• 升级相关：数据库、应用、中间件、操作系统、网络、包括硬件升级

真正决定高可用系统的本质原因

从上面这些会影响高可用的SLA的因素，你看到了什么？如果你还是只看到了技术方面或是软件设计的东西，那么你只看到了冰山一角。我们再仔细想一想， 那个5个9的SLA在一年内只能是5分钟的不可用时间，5分钟啊，如果按一年只出1次故障，你也得在五分钟内恢复故障，让我们想想，这意味着什么？

如果你没有一套科学的牛逼的软件工程的管理，没有牛逼先进的自动化的运维工具，没有技术能力很牛逼的工程师团队，怎么可能出现高可用的系统啊。

是的， 要干出高可用的系统，这TMD就是一套严谨科学的工程管理，其中包括但不限于了：

• 软件的设计、编码、测试、上线和软件配置管理的水平
• 工程师的人员技能水平
• 运维的管理和技术水平
• 数据中心的运营管理水平
• 依赖于第三方服务的管理水平

深层交的东西则是——对工程这门科学的尊重：

• 对待技术的态度
• 一个公司的工程文化
• 领导者对工程的尊重

所以，以后有人在你面前提高可用，你要看的不是他的技术设计，而还要看看他们的工程能力，看看他们公司是否真正的尊重工程这门科学。

其它

有好些非技术甚至技术人员和我说过，做个APP做个网站，不就是找几个码农过来写写代码嘛。等系统不可用的时候，他们才会明白，要找技术能力比较强的人，但是， 就算你和他们讲一万遍道理，他们也很难会明白写代码怎么就是一种工程了，而工程怎么就成了一门科学了。其实，很多做技术的人都不明白这个道理。

包括很多技术人员也永远不会理解，为什么要做好多像Code Review、自动化运维、自动化测试、持续集成之类这样很无聊的东西。就像我在《 从Code Review 谈如何做技术》中提到的，阿里很多的工程师，架构师/专家，甚至资深架构师都没有这个意识，当然，这不怪他们，因为经历决定思维方式，他们的经历的是民用级的系统，做的都是堆功能的工作，的确不需要。

看完这些，最后让我们都扪心自问一下，你还敢说你的系统是高可用的了么？ ;-)

（全文完）

关注CoolShell微信公众账号可以在手机端搜索文章

前言

2016年3月修改，结合自己的工作和平时学习的体验重新谈一下为什么要进行代码优化。在修改之前，我的说法是这样的：

这个观点，在现在看来，是要进行代码优化的一个原因，但不全对。在机械工艺发展的今天，服务器动辄8核、16核，64位CPU，代码执行效率非常高，StringBuilder替换StringBuffer、ArrayList替换Vector，对于代码运行效率的提升是微乎其微的，即使是项目中的每个点都注意到了，代码运行也看不出什么明显的变化。

我认为，代码优化的最重要的作用应该是： 避免未知的错误。在代码上线运行的过程中，往往会出现很多我们意想不到的错误，因为线上环境和开发环境是非常不同的，错误定位到最后往往是一个非常小的原因。然而为了解决这个错误，我们需要先自验证、再打包出待替换的class文件、暂停业务并重启，对于一个成熟的项目而言，最后一条其实影响是非常大的，这意味着这段时间用户无法访问应用。因此，在写代码的时候，从源头开始注意各种细节，权衡并使用最优的选择，将会很大程度上避免出现未知的错误，从长远看也极大的降低了工作量。

代码优化的目标是：

1、减小代码的体积

2、提高代码运行的效率

本文的内容有些来自网络，有些来自平时工作和学习，当然这不重要，重要的是这些代码优化的细节是否真真正正地有用。那本文会保持长期更新，只要有遇到值得分享的代码优化细节，就会不定时地更新此文。

代码优化细节

1、尽量指定类、方法的final修饰符

带有final修饰符的类是不可派生的。在Java核心API中，有许多应用final的例子，例如java.lang.String，整个类都是final的。为类指定final修饰符可以让类不可以被继承，为方法指定final修饰符可以让方法不可以被重写。如果指定了一个类为final，则该类所有的方法都是final的。Java编译器会寻找机会内联所有的final方法，内联对于提升Java运行效率作用重大，具体参见 Java运行期优化。此举能够使性能平均提高50%。

2、尽量重用对象

特别是String对象的使用，出现字符串连接时应该使用StringBuilder/StringBuffer代替。由于Java虚拟机不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理，因此，生成过多的对象将会给程序的性能带来很大的影响。

3、尽可能使用局部变量

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中速度较快，其他变量，如静态变量、实例变量等，都在堆中创建，速度较慢。另外，栈中创建的变量，随着方法的运行结束，这些内容就没了，不需要额外的垃圾回收。

4、及时关闭流

Java编程过程中，进行数据库连接、I/O流操作时务必小心，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销，稍有不慎，将会导致严重的后果。

5、尽量减少对变量的重复计算

明确一个概念，对方法的调用，即使方法中只有一句语句，也是有消耗的，包括创建栈帧、调用方法时保护现场、调用方法完毕时恢复现场等。所以例如下面的操作：

for (int i = 0; i < list.size(); i++)
{...}

建议替换为：

for (int i = 0, length = list.size(); i < length; i++)
{...}

这样，在list.size()很大的时候，就减少了很多的消耗

6、尽量采用懒加载的策略，即在需要的时候才创建

例如：

String str = "aaa";
if (i == 1)
{
　　list.add(str);
}

建议替换为：

if (i == 1)
{
　　String str = "aaa";
　　list.add(str);
}

7、慎用异常

异常对性能不利。抛出异常首先要创建一个新的对象，Throwable接口的构造函数调用名为fillInStackTrace()的本地同步方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，Java虚拟机就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。

8、不要在循环中使用try…catch…，应该把其放在最外层

根据网友们提出的意见，这一点我认为值得商榷

9、如果能估计到待添加的内容长度，为底层以数组方式实现的集合、工具类指定初始长度

比如ArrayList、LinkedLlist、StringBuilder、StringBuffer、HashMap、HashSet等等，以StringBuilder为例：

（1）StringBuilder()　　　　　　// 默认分配16个字符的空间

（2）StringBuilder(int size)　　// 默认分配size个字符的空间

（3）StringBuilder(String str)　// 默认分配16个字符+str.length()个字符空间

可以通过类（这里指的不仅仅是上面的StringBuilder）的构造函数来设定它的初始化容量，这样可以明显地提升性能。比如StringBuilder吧，length表示当前的StringBuilder能保持的字符数量。因为当StringBuilder达到最大容量的时候，它会将自身容量增加到当前的2倍再加2，无论何时只要StringBuilder达到它的最大容量，它就不得不创建一个新的字符数组然后将旧的字符数组内容拷贝到新字符数组中—-这是十分耗费性能的一个操作。试想，如果能预估到字符数组中大概要存放5000个字符而不指定长度，最接近5000的2次幂是4096，每次扩容加的2不管，那么：

（1）在4096 的基础上，再申请8194个大小的字符数组，加起来相当于一次申请了12290个大小的字符数组，如果一开始能指定5000个大小的字符数组，就节省了一倍以上的空间

（2）把原来的4096个字符拷贝到新的的字符数组中去

这样，既浪费内存空间又降低代码运行效率。所以，给底层以数组实现的集合、工具类设置一个合理的初始化容量是错不了的，这会带来立竿见影的效果。但是，注意， 像HashMap这种是以数组+链表实现的集合，别把初始大小和你估计的大小设置得一样，因为一个table上只连接一个对象的可能性几乎为0。初始大小建议设置为2的N次幂，如果能估计到有2000个元素，设置成new HashMap(128)、new HashMap(256)都可以。

10、当复制大量数据时，使用System.arraycopy()命令

11、乘法和除法使用移位操作

例如：

for (val = 0; val < 100000; val += 5)
{
　　a = val * 8;
　　b = val / 2;
}

用移位操作可以极大地提高性能，因为在计算机底层，对位的操作是最方便、最快的，因此建议修改为：

for (val = 0; val < 100000; val += 5)
{
　　a = val << 3;
　　b = val >> 1;
}

移位操作虽然快，但是可能会使代码不太好理解，因此最好加上相应的注释。

12、循环内不要不断创建对象引用

例如：

for (int i = 1; i <= count; i++)
{
    Object obj = new Object();    
}

这种做法会导致内存中有count份Object对象引用存在，count很大的话，就耗费内存了，建议为改为：

Object obj = null;
for (int i = 0; i <= count; i++)
{
    obj = new Object();
}

这样的话，内存中只有一份Object对象引用，每次new Object()的时候，Object对象引用指向不同的Object罢了，但是内存中只有一份，这样就大大节省了内存空间了。

13、基于效率和类型检查的考虑，应该尽可能使用array，无法确定数组大小时才使用ArrayList

14、尽量使用HashMap、ArrayList、StringBuilder，除非线程安全需要，否则不推荐使用Hashtable、Vector、StringBuffer，后三者由于使用同步机制而导致了性能开销

15、不要将数组声明为public static final

因为这毫无意义，这样只是定义了引用为static final，数组的内容还是可以随意改变的，将数组声明为public更是一个安全漏洞，这意味着这个数组可以被外部类所改变

16、尽量在合适的场合使用单例

使用单例可以减轻加载的负担、缩短加载的时间、提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：

（1）控制资源的使用，通过线程同步来控制资源的并发访问

（2）控制实例的产生，以达到节约资源的目的

（3）控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信

17、尽量避免随意使用静态变量

要知道，当某个对象被定义为static的变量所引用，那么gc通常是不会回收这个对象所占有的堆内存的，如：

public class A
{
    private static B b = new B();  
}

此时静态变量b的生命周期与A类相同，如果A类不被卸载，那么引用B指向的B对象会常驻内存，直到程序终止

18、及时清除不再需要的会话

为了清除不再活动的会话，许多应用服务器都有默认的会话超时时间，一般为30分钟。当应用服务器需要保存更多的会话时，如果内存不足，那么操作系统会把部分数据转移到磁盘，应用服务器也可能根据MRU（最近最频繁使用）算法把部分不活跃的会话转储到磁盘，甚至可能抛出内存不足的异常。如果会话要被转储到磁盘，那么必须要先被序列化，在大规模集群中，对对象进行序列化的代价是很昂贵的。因此，当会话不再需要时，应当及时调用HttpSession的invalidate()方法清除会话。

19、实现RandomAccess接口的集合比如ArrayList，应当使用最普通的for循环而不是foreach循环来遍历

这是JDK推荐给用户的。JDK API对于RandomAccess接口的解释是：实现RandomAccess接口用来表明其支持快速随机访问，此接口的主要目的是允许一般的算法更改其行为，从而将其应用到随机或连续访问列表时能提供良好的性能。实际经验表明， 实现RandomAccess接口的类实例，假如是随机访问的，使用普通for循环效率将高于使用foreach循环；反过来，如果是顺序访问的，则使用Iterator会效率更高。可以使用类似如下的代码作判断：

if (list instanceof RandomAccess)
{
    for (int i = 0; i < list.size(); i++){}
}
else
{
    Iterator<?> iterator = list.iterable();
    while (iterator.hasNext()){iterator.next()}
}

foreach循环的底层实现原理就是迭代器Iterator，参见 Java语法糖1：可变长度参数以及foreach循环原理。所以后半句”反过来，如果是顺序访问的，则使用Iterator会效率更高”的意思就是顺序访问的那些类实例，使用foreach循环去遍历。

20、使用同步代码块替代同步方法

这点在多线程模块中的 synchronized锁方法块一文中已经讲得很清楚了，除非能确定一整个方法都是需要进行同步的，否则尽量使用同步代码块，避免对那些不需要进行同步的代码也进行了同步，影响了代码执行效率。

21、将常量声明为static final，并以大写命名

这样在编译期间就可以把这些内容放入常量池中，避免运行期间计算生成常量的值。另外，将常量的名字以大写命名也可以方便区分出常量与变量

22、不要创建一些不使用的对象，不要导入一些不使用的类

这毫无意义，如果代码中出现”The value of the local variable i is not used”、”The import java.util is never used”，那么请删除这些无用的内容

23、程序运行过程中避免使用反射

关于，请参见 反射。反射是Java提供给用户一个很强大的功能，功能强大往往意味着效率不高。不建议在程序运行过程中使用尤其是频繁使用反射机制，特别是Method的invoke方法，如果确实有必要，一种建议性的做法是将那些需要通过反射加载的类在项目启动的时候通过反射实例化出一个对象并放入内存—-用户只关心和对端交互的时候获取最快的响应速度，并不关心对端的项目启动花多久时间。

24、使用数据库连接池和线程池

这两个池都是用于重用对象的，前者可以避免频繁地打开和关闭连接，后者可以避免频繁地创建和销毁线程

25、使用带缓冲的输入输出流进行IO操作

带缓冲的输入输出流，即BufferedReader、BufferedWriter、BufferedInputStream、BufferedOutputStream，这可以极大地提升IO效率

26、顺序插入和随机访问比较多的场景使用ArrayList，元素删除和中间插入比较多的场景使用LinkedList

这个，理解ArrayList和LinkedList的原理就知道了

27、不要让public方法中有太多的形参

public方法即对外提供的方法，如果给这些方法太多形参的话主要有两点坏处：

1、违反了面向对象的编程思想，Java讲求一切都是对象，太多的形参，和面向对象的编程思想并不契合

2、参数太多势必导致方法调用的出错概率增加

至于这个”太多”指的是多少个，3、4个吧。比如我们用JDBC写一个insertStudentInfo方法，有10个学生信息字段要插如Student表中，可以把这10个参数封装在一个实体类中，作为insert方法的形参

28、字符串变量和字符串常量equals的时候将字符串常量写在前面

这是一个比较常见的小技巧了，如果有以下代码：

String str = "123";
if (str.equals("123"))
{
    ...
}

建议修改为：

String str = "123";
if ("123".equals(str))
{
    ...
}

这么做主要是可以避免空指针异常

29、请知道，在java中if (i == 1)和if (1 == i)是没有区别的，但从阅读习惯上讲，建议使用前者

平时有人问，”if (i == 1)”和”if (1== i)”有没有区别，这就要从C/C++讲起。

在C/C++中，”if (i == 1)”判断条件成立，是以0与非0为基准的，0表示false，非0表示true，如果有这么一段代码：

int i = 2;
if (i == 1)
{
    ...
}
else
{
    ...
}

C/C++判断”i==1″不成立，所以以0表示，即false。但是如果：

int i = 2;
if (i = 1)
{
    ...
}
else
{
    ...
}

万一程序员一个不小心，把”if (i == 1)”写成”if (i = 1)”，这样就有问题了。在if之内将i赋值为1，if判断里面的内容非0，返回的就是true了，但是明明i为2，比较的值是1，应该返回的false。这种情况在C/C++的开发中是很可能发生的并且会导致一些难以理解的错误产生，所以，为了避免开发者在if语句中不正确的赋值操作，建议将if语句写为：

int i = 2;
if (1 == i)
{
    ...
}
else
{
    ...
}

这样，即使开发者不小心写成了”1 = i”，C/C++编译器也可以第一时间检查出来，因为我们可以对一个变量赋值i为1，但是不能对一个常量赋值1为i。

但是，在Java中，C/C++这种”if (i = 1)”的语法是不可能出现的，因为一旦写了这种语法，Java就会编译报错” Type mismatch: cannot convert from int to boolean“。但是，尽管Java的”if (i == 1)”和”if (1 == i)”在语义上没有任何区别，但是从阅读习惯上讲，建议使用前者会更好些。

30、不要对数组使用toString()方法

看一下对数组使用toString()打印出来的是什么：

public static void main(String[] args)
{
    int[] is = new int[]{1, 2, 3};
    System.out.println(is.toString());
}

结果是：

[I@18a992f

本意是想打印出数组内容，却有可能因为数组引用is为空而导致空指针异常。不过虽然对数组toString()没有意义，但是对集合toString()是可以打印出集合里面的内容的，因为集合的父类AbstractCollections<E>重写了Object的toString()方法。

32、不要对超出范围的基本数据类型做向下强制转型

这绝不会得到想要的结果：

public static void main(String[] args)
{
    long l = 12345678901234L;
    int i = (int)l;
    System.out.println(i);
}

我们可能期望得到其中的某几位，但是结果却是：

1942892530

解释一下。Java中long是8个字节64位的，所以12345678901234在计算机中的表示应该是：

0000 0000 0000 0000 0000 1011 0011 1010 0111 0011 1100 1110 0010 1111 1111 0010

一个int型数据是4个字节32位的，从低位取出上面这串二进制数据的前32位是：

0111 0011 1100 1110 0010 1111 1111 0010

这串二进制表示为十进制1942892530，所以就是我们上面的控制台上输出的内容。从这个例子上还能顺便得到两个结论：

1、整型默认的数据类型是int，long l = 12345678901234L，这个数字已经超出了int的范围了，所以最后有一个L，表示这是一个long型数。顺便，浮点型的默认类型是double，所以定义float的时候要写成”"float f = 3.5f”

2、接下来再写一句”int ii = l + i;”会报错，因为long + int是一个long，不能赋值给int

33、公用的集合类中不使用的数据一定要及时remove掉

如果一个集合类是公用的（也就是说不是方法里面的属性），那么这个集合里面的元素是不会自动释放的，因为始终有引用指向它们。所以，如果公用集合里面的某些数据不使用而不去remove掉它们，那么将会造成这个公用集合不断增大，使得系统有内存泄露的隐患。

34、把一个基本数据类型转为字符串，基本数据类型.toString()是最快的方式、String.valueOf(数据)次之、数据+”"最慢

把一个基本数据类型转为一般有三种方式，我有一个Integer型数据i，可以使用i.toString()、String.valueOf(i)、i+”"三种方式，三种方式的效率如何，看一个测试：

public static void main(String[] args)
{
    int loopTime = 50000;
    Integer i = 0;
    long startTime = System.currentTimeMillis();
    for (int j = 0; j < loopTime; j++)
    {
        String str = String.valueOf(i);
    }    
    System.out.println("String.valueOf()：" + (System.currentTimeMillis() - startTime) + "ms");
    startTime = System.currentTimeMillis();
    for (int j = 0; j < loopTime; j++)
    {
        String str = i.toString();
    }    
    System.out.println("Integer.toString()：" + (System.currentTimeMillis() - startTime) + "ms");
    startTime = System.currentTimeMillis();
    for (int j = 0; j < loopTime; j++)
    {
        String str = i + "";
    }    
    System.out.println("i + \"\"：" + (System.currentTimeMillis() - startTime) + "ms");
}

运行结果为：

String.valueOf()：11ms
Integer.toString()：5ms
i + ""：25ms

所以以后遇到把一个基本数据类型转为String的时候，优先考虑使用toString()方法。至于为什么，很简单：

1、String.valueOf()方法底层调用了Integer.toString()方法，但是会在调用前做空判断

2、Integer.toString()方法就不说了，直接调用了

3、i + “”底层使用了StringBuilder实现，先用append方法拼接，再用toString()方法获取字符串

三者对比下来，明显是2最快、1次之、3最慢

35、使用最有效率的方式去遍历Map

遍历Map的方式有很多，通常场景下我们需要的是遍历Map中的Key和Value，那么推荐使用的、效率最高的方式是：

public static void main(String[] args)
{
    HashMap<String, String> hm = new HashMap<String, String>();
    hm.put("111", "222");

    Set<Map.Entry<String, String>> entrySet = hm.entrySet();
    Iterator<Map.Entry<String, String>> iter = entrySet.iterator();
    while (iter.hasNext())
    {
        Map.Entry<String, String> entry = iter.next();
        System.out.println(entry.getKey() + "\t" + entry.getValue());
    }
}

如果你只是想遍历一下这个Map的key值，那用”Set<String> keySet = hm.keySet();”会比较合适一些

36、对资源的close()建议分开操作

意思是，比如我有这么一段代码：

try
{
    XXX.close();
    YYY.close();
}
catch (Exception e)
{
    ...
}

建议修改为：

try
{
    XXX.close();
}
catch (Exception e)
{
    ...
}
try
{
    YYY.close();
}
catch (Exception e)
{
    ...
}

虽然有些麻烦，却能避免资源泄露。我们想，如果没有修改过的代码，万一XXX.close()抛异常了，那么就进入了catch块中了，YYY.close()不会执行，YYY这块资源就不会回收了，一直占用着，这样的代码一多，是可能引起资源句柄泄露的。而改为下面的写法之后，就保证了无论如何XXX和YYY都会被close掉

37、对于ThreadLocal使用前或者使用后一定要先remove

当前基本所有的项目都使用了线程池技术，这非常好，可以动态配置线程数、可以重用线程。

然而，如果你在项目中使用到了ThreadLocal，一定要记得使用前或者使用后remove一下。这是因为上面提到了线程池技术做的是一个 线程重用，这意味着代码运行过程中，一条线程使用完毕，并不会被销毁而是等待下一次的使用。我们看一下Thread类中，持有ThreadLocal.ThreadLocalMap的引用：

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

线程不销毁意味着上条线程set的ThreadLocal.ThreadLocalMap中的数据依然存在，那么在下一条线程重用这个Thread的时候，很可能get到的是上条线程set的数据而不是自己想要的内容。

这个问题非常隐晦，一旦出现这个原因导致的错误，没有相关经验或者没有扎实的基础非常难发现这个问题，因此在写代码的时候就要注意这一点，这将给你后续减少很多的工作量。

后记

优秀的代码来自每一点点小小的优化，关注每一个细节，不仅仅能提升程序运行效率，同样可以规避许多未知的问题。

相关文章

• 高吞吐量系统设计优化建议
• Linkedin工程师是如何优化他们的Java代码的
• Android性能优化案例研究（下）
• JVM性能优化， Part 2 ―― 编译器
• Java8学习：Lambda表达式、Stream API和功能性接口 — 教程、资源、书籍和实例
• 迭代与枚举
• JVM必备指南
• 在什么情况下，Java比C++慢很多？
• 跟我学Spring3（6.7）： 通知顺序
• 微信开发之通过代理调试本地项目

上一篇文章我介绍了 HTTP/2 协议，它只有在 HTTPS 环境才会生效。

为了升级到 HTTP/2 协议，必须先启用 HTTPS。如果你不了解 HTTPS 协议（学名 TLS 协议），可以参考我以前的文章。

• 《HTTPS 协议概述》
• 《图解 HTTPS 协议》
• 《HTTPS 协议的七个误解》
• 《HTTPS 协议的延迟有多大？》

本文介绍如何将一个 HTTP 网站升级到 HTTPS 。

一、获取证书

升级到 HTTPS 协议的第一步，就是要获得一张证书。

证书是一个二进制文件，里面包含经过认证的网站公钥和一些元数据，要从经销商购买。

• GoGetSSL
• SSLs.com
• SSLmate.com

证书有很多类型，首先分为三种认证级别。

• 域名认证（Domain Validation）：最低级别认证，可以确认申请人拥有这个域名。对于这种证书，浏览器会在地址栏显示一把锁。
• 公司认证（Company Validation）：确认域名所有人是哪一家公司，证书里面会包含公司信息。
• 扩展认证（Extended Validation）：最高级别的认证，浏览器地址栏会显示公司名。

还分为三种覆盖范围。

• 单域名证书：只能用于单一域名， foo.com的证书不能用于 www.foo.com
• 通配符证书：可以用于某个域名及其所有一级子域名，比如 *.foo.com的证书可以用于 foo.com，也可以用于 www.foo.com
• 多域名证书：可以用于多个域名，比如 foo.com和 bar.com

认证级别越高、覆盖范围越广的证书，价格越贵。

还有一个免费证书的选择。为了推广HTTPS协议，电子前哨基金会EFF成立了 Let’s Encrypt，提供免费证书（ 教程和 工具）。

拿到证书以后，可以用 SSL Certificate Check检查一下，信息是否正确。

二、安装证书

证书可以放在 /etc/ssl目录（Linux 系统），然后根据你使用的Web服务器进行配置。

• 证书配置文件生成器，by Mozilla
• 配置文件模板，by SSLMate

如果使用 Let’s Encrypt 证书，请使用自动安装工具 Certbot。

安装成功后，使用 SSL Labs Server Test检查一下证书是否生效。

三、修改链接

下一步，网页加载的 HTTP 资源，要全部改成 HTTPS 链接。因为加密网页内如果有非加密的资源，浏览器是不会加载那些资源的。

<script src="    http://foo.com/jquery.js"></script>

上面这行加载命令，有两种改法。

<!-- 改法一 --><script src="    https://foo.com/jquery.js"></script><!-- 改法二 --><script src="//foo.com/jquery.js"></script>

其中，改法二会根据当前网页的协议，加载相同协议的外部资源，更灵活一些。

另外，如果页面头部用到了 rel="canonical"，也要改成HTTPS网址。

<link rel="canonical" href="    https://foo.com/bar.html" />

四、301重定向

下一步，修改 Web 服务器的配置文件，使用 301 重定向，将 HTTP 协议的访问导向 HTTPS 协议。

Nginx 的写法。

server {
  listen 80;
  server_name domain.com www.domain.com;
  return 301     https://domain.com$request_uri;
}

Apache 的写法（ .htaccess文件）。

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

五、安全措施

以下措施可以进一步保证通信安全。

5.1 HTTP Strict Transport Security (HSTS)

访问网站时，用户很少直接在地址栏输入 https://，总是通过点击链接，或者3xx重定向，从 HTTP页面进入 HTTPS页面。攻击者完全可以在用户发出 HTTP请求时，劫持并篡改该请求。

另一种情况是恶意网站使用自签名证书，冒充另一个网站，这时浏览器会给出警告，但是许多用户会忽略警告继续访问。

“HTTP严格传输安全”（简称 HSTS）的作用，就是强制浏览器只能发出 HTTPS请求，并阻止用户接受不安全的证书。

它在网站的响应头里面，加入一个强制性声明。以下例子摘自 维基百科。

Strict-Transport-Security: max-age=31536000; includeSubDomains

上面这段头信息有两个作用。

（1）在接下来的一年（即31536000秒）中，浏览器只要向 example.com或其子域名发送HTTP请求时，必须采用HTTPS来发起连接。用户点击超链接或在地址栏输入 http://www.example.com/，浏览器应当自动将 http转写成 https，然后直接向 https://www.example.com/发送请求。

（2）在接下来的一年中，如果 example.com服务器发送的证书无效，用户不能忽略浏览器警告，将无法继续访问该网站。

HSTS 很大程度上解决了 SSL 剥离攻击。只要浏览器曾经与服务器建立过一次安全连接，之后浏览器会强制使用 HTTPS，即使链接被换成了 HTTP。

该方法的主要不足是，用户首次访问网站发出HTTP请求时，是不受HSTS保护的。

如果想要全面分析网站的安全程度，可以使用 Mozilla 的 Observatory。

5.2 Cookie

另一个需要注意的地方是，确保浏览器只在使用 HTTPS 时，才发送Cookie。

网站响应头里面， Set-Cookie字段加上 Secure标志即可。

Set-Cookie: LSID=DQAAAK...Eaem_vYg; Secure

六、参考链接

• How To Migrate To HTTPS, by Chris Palmer
• Complete Guide – How to Migrate from HTTP to HTTPS, by KeyCDN
• What You Need to Know About Changing From Http to Https, by Matt Mansfield

（完）

文章出处

本文的目标有两个：

1、学会使用11大Java开源中文分词器

2、对比分析11大Java开源中文分词器的分词效果

本文给出了11大Java开源中文分词的使用方法以及分词结果对比代码，至于效果哪个好，那要用的人结合自己的应用场景自己来判断。

11大Java开源中文分词器，不同的分词器有不同的用法，定义的接口也不一样，我们先定义一个统一的接口：

/**
 * 获取文本的所有分词结果, 对比不同分词器结果
 * @author 杨尚川
 */
public interface WordSegmenter {
    /**
     * 获取文本的所有分词结果
     * @param text 文本
     * @return 所有的分词结果，去除重复
     */
    default public Set<String> seg(String text) {
        return segMore(text).values().stream().collect(Collectors.toSet());
    }
    /**
     * 获取文本的所有分词结果
     * @param text 文本
     * @return 所有的分词结果，KEY 为分词器模式，VALUE 为分词器结果
     */
    public Map<String, String> segMore(String text);
}

从上面的定义我们知道，在Java中，同样的方法名称和参数，但是返回值不同，这种情况不可以使用重载。

这两个方法的区别在于返回值，每一个分词器都可能有多种分词模式，每种模式的分词结果都可能不相同，第一个方法忽略分词器模式，返回所有模式的所有不重复分词结果，第二个方法返回每一种分词器模式及其对应的分词结果。

在这里，需要注意的是我们使用了Java8中的新特性默认方法，并使用stream把一个map的value转换为不重复的集合。

下面我们利用这11大分词器来实现这个接口：

1、word分词器

@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    for(SegmentationAlgorithm segmentationAlgorithm : SegmentationAlgorithm.values()){
        map.put(segmentationAlgorithm.getDes(), seg(text, segmentationAlgorithm));
    }
    return map;
}
private static String seg(String text, SegmentationAlgorithm segmentationAlgorithm) {
    StringBuilder result = new StringBuilder();
    for(Word word : WordSegmenter.segWithStopWords(text, segmentationAlgorithm)){
        result.append(word.getText()).append(" ");
    }
    return result.toString();
}

2、Ansj分词器

@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();

    StringBuilder result = new StringBuilder();
    for(Term term : BaseAnalysis.parse(text)){
        result.append(term.getName()).append(" ");
    }
    map.put("BaseAnalysis", result.toString());

    result.setLength(0);
    for(Term term : ToAnalysis.parse(text)){
        result.append(term.getName()).append(" ");
    }
    map.put("ToAnalysis", result.toString());

    result.setLength(0);
    for(Term term : NlpAnalysis.parse(text)){
        result.append(term.getName()).append(" ");
    }
    map.put("NlpAnalysis", result.toString());

    result.setLength(0);
    for(Term term : IndexAnalysis.parse(text)){
        result.append(term.getName()).append(" ");
    }
    map.put("IndexAnalysis", result.toString());

    return map;
}

3、Stanford分词器

private static final StanfordCoreNLP CTB = new StanfordCoreNLP("StanfordCoreNLP-chinese-ctb");
private static final StanfordCoreNLP PKU = new StanfordCoreNLP("StanfordCoreNLP-chinese-pku");
private static final PrintStream NULL_PRINT_STREAM = new PrintStream(new NullOutputStream(), false);
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put("Stanford Beijing University segmentation", seg(PKU, text));
    map.put("Stanford Chinese Treebank segmentation", seg(CTB, text));
    return map;
}
private static String seg(StanfordCoreNLP stanfordCoreNLP, String text){
    PrintStream err = System.err;
    System.setErr(NULL_PRINT_STREAM);
    Annotation document = new Annotation(text);
    stanfordCoreNLP.annotate(document);
    List<CoreMap> sentences = document.get(CoreAnnotations.SentencesAnnotation.class);
    StringBuilder result = new StringBuilder();
    for(CoreMap sentence: sentences) {
        for (CoreLabel token: sentence.get(CoreAnnotations.TokensAnnotation.class)) {
            String word = token.get(CoreAnnotations.TextAnnotation.class);;
            result.append(word).append(" ");
        }
    }
    System.setErr(err);
    return result.toString();
}

4、FudanNLP分词器

private static CWSTagger tagger = null;
static{
    try{
        tagger = new CWSTagger("lib/fudannlp_seg.m");
        tagger.setEnFilter(true);
    }catch(Exception e){
        e.printStackTrace();
    }
}
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put("FudanNLP", tagger.tag(text));
    return map;
}

5、Jieba分词器

private static final JiebaSegmenter JIEBA_SEGMENTER = new JiebaSegmenter();
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put("INDEX", seg(text, SegMode.INDEX));
    map.put("SEARCH", seg(text, SegMode.SEARCH));
    return map;
}
private static String seg(String text, SegMode segMode) {
    StringBuilder result = new StringBuilder();                
    for(SegToken token : JIEBA_SEGMENTER.process(text, segMode)){
        result.append(token.word.getToken()).append(" ");
    }
    return result.toString(); 
}

6、Jcseg分词器

private static final JcsegTaskConfig CONFIG = new JcsegTaskConfig();
private static final ADictionary DIC = DictionaryFactory.createDefaultDictionary(CONFIG);
static {
    CONFIG.setLoadCJKSyn(false);
    CONFIG.setLoadCJKPinyin(false);
}
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();

    map.put("复杂模式", segText(text, JcsegTaskConfig.COMPLEX_MODE));
    map.put("简易模式", segText(text, JcsegTaskConfig.SIMPLE_MODE));

    return map;
}
private String segText(String text, int segMode) {
    StringBuilder result = new StringBuilder();        
    try {
        ISegment seg = SegmentFactory.createJcseg(segMode, new Object[]{new StringReader(text), CONFIG, DIC});
        IWord word = null;
        while((word=seg.next())!=null) {         
            result.append(word.getValue()).append(" ");
        }
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
    return result.toString();
}

7、MMSeg4j分词器

private static final Dictionary DIC = Dictionary.getInstance();
private static final SimpleSeg SIMPLE_SEG = new SimpleSeg(DIC);
private static final ComplexSeg COMPLEX_SEG = new ComplexSeg(DIC);
private static final MaxWordSeg MAX_WORD_SEG = new MaxWordSeg(DIC);
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put(SIMPLE_SEG.getClass().getSimpleName(), segText(text, SIMPLE_SEG));
    map.put(COMPLEX_SEG.getClass().getSimpleName(), segText(text, COMPLEX_SEG));
    map.put(MAX_WORD_SEG.getClass().getSimpleName(), segText(text, MAX_WORD_SEG));
    return map;
}
private String segText(String text, Seg seg) {
    StringBuilder result = new StringBuilder();
    MMSeg mmSeg = new MMSeg(new StringReader(text), seg);        
    try {
        Word word = null;
        while((word=mmSeg.next())!=null) {       
            result.append(word.getString()).append(" ");
        }
    } catch (IOException ex) {
        throw new RuntimeException(ex);
    }
    return result.toString();
}

8、IKAnalyzer分词器

@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();

    map.put("智能切分", segText(text, true));
    map.put("细粒度切分", segText(text, false));

    return map;
}
private String segText(String text, boolean useSmart) {
    StringBuilder result = new StringBuilder();
    IKSegmenter ik = new IKSegmenter(new StringReader(text), useSmart);        
    try {
        Lexeme word = null;
        while((word=ik.next())!=null) {          
            result.append(word.getLexemeText()).append(" ");
        }
    } catch (IOException ex) {
        throw new RuntimeException(ex);
    }
    return result.toString();
}

9、Paoding分词器

private static final PaodingAnalyzer ANALYZER = new PaodingAnalyzer();
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();

    map.put("MOST_WORDS_MODE", seg(text, PaodingAnalyzer.MOST_WORDS_MODE));
    map.put("MAX_WORD_LENGTH_MODE", seg(text, PaodingAnalyzer.MAX_WORD_LENGTH_MODE));

    return map;
}
private static String seg(String text, int mode){
    ANALYZER.setMode(mode);
    StringBuilder result = new StringBuilder();
    try {
        Token reusableToken = new Token();
        TokenStream stream = ANALYZER.tokenStream("", new StringReader(text));
        Token token = null;
        while((token = stream.next(reusableToken)) != null){
            result.append(token.term()).append(" ");
        }
    } catch (Exception ex) {
        throw new RuntimeException(ex);
    }
    return result.toString();          
}

10、smartcn分词器

private static final SmartChineseAnalyzer SMART_CHINESE_ANALYZER = new SmartChineseAnalyzer();
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put("smartcn", segText(text));
    return map;
}
private static String segText(String text) {
    StringBuilder result = new StringBuilder();
    try {
        TokenStream tokenStream = SMART_CHINESE_ANALYZER.tokenStream("text", new StringReader(text));
        tokenStream.reset();
        while (tokenStream.incrementToken()){
            CharTermAttribute charTermAttribute = tokenStream.getAttribute(CharTermAttribute.class);
            result.append(charTermAttribute.toString()).append(" ");
        }
        tokenStream.close();
    }catch (Exception e){
        e.printStackTrace();
    }
    return result.toString();
}

11、HanLP分词器

private static final Segment N_SHORT_SEGMENT = new NShortSegment().enableCustomDictionary(false).enablePlaceRecognize(true).enableOrganizationRecognize(true);
private static final Segment DIJKSTRA_SEGMENT = new DijkstraSegment().enableCustomDictionary(false).enablePlaceRecognize(true).enableOrganizationRecognize(true);
@Override
public Map<String, String> segMore(String text) {
    Map<String, String> map = new HashMap<>();
    map.put("标准分词", standard(text));
    map.put("NLP分词", nlp(text));
    map.put("索引分词", index(text));
    map.put("N-最短路径分词", nShort(text));
    map.put("最短路径分词", shortest(text));
    map.put("极速词典分词", speed(text));
    return map;
}
private static String standard(String text) {
    StringBuilder result = new StringBuilder();
    StandardTokenizer.segment(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}
private static String nlp(String text) {
    StringBuilder result = new StringBuilder();
    NLPTokenizer.segment(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}
private static String index(String text) {
    StringBuilder result = new StringBuilder();
    IndexTokenizer.segment(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}
private static String speed(String text) {
    StringBuilder result = new StringBuilder();
    SpeedTokenizer.segment(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}
private static String nShort(String text) {
    StringBuilder result = new StringBuilder();
    N_SHORT_SEGMENT.seg(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}
private static String shortest(String text) {
    StringBuilder result = new StringBuilder();
    DIJKSTRA_SEGMENT.seg(text).forEach(term->result.append(term.word).append(" "));
    return result.toString();
}

现在我们已经实现了本文的第一个目的：学会使用11大Java开源中文分词器。

最后我们来实现本文的第二个目的：对比分析11大Java开源中文分词器的分词效果，程序如下：

public static Map<String, Set<String>> contrast(String text){
    Map<String, Set<String>> map = new LinkedHashMap<>();
    map.put("word分词器", new WordEvaluation().seg(text));
    map.put("Stanford分词器", new StanfordEvaluation().seg(text));
    map.put("Ansj分词器", new AnsjEvaluation().seg(text));
    map.put("HanLP分词器", new HanLPEvaluation().seg(text));
    map.put("FudanNLP分词器", new FudanNLPEvaluation().seg(text));
    map.put("Jieba分词器", new JiebaEvaluation().seg(text));
    map.put("Jcseg分词器", new JcsegEvaluation().seg(text));
    map.put("MMSeg4j分词器", new MMSeg4jEvaluation().seg(text));
    map.put("IKAnalyzer分词器", new IKAnalyzerEvaluation().seg(text));
    map.put("smartcn分词器", new SmartCNEvaluation().seg(text));
    return map;
}
public static Map<String, Map<String, String>> contrastMore(String text){
    Map<String, Map<String, String>> map = new LinkedHashMap<>();
    map.put("word分词器", new WordEvaluation().segMore(text));
    map.put("Stanford分词器", new StanfordEvaluation().segMore(text));
    map.put("Ansj分词器", new AnsjEvaluation().segMore(text));
    map.put("HanLP分词器", new HanLPEvaluation().segMore(text));
    map.put("FudanNLP分词器", new FudanNLPEvaluation().segMore(text));
    map.put("Jieba分词器", new JiebaEvaluation().segMore(text));
    map.put("Jcseg分词器", new JcsegEvaluation().segMore(text));
    map.put("MMSeg4j分词器", new MMSeg4jEvaluation().segMore(text));
    map.put("IKAnalyzer分词器", new IKAnalyzerEvaluation().segMore(text));
    map.put("smartcn分词器", new SmartCNEvaluation().segMore(text));
    return map;
}
public static void show(Map<String, Set<String>> map){
    map.keySet().forEach(k -> {
        System.out.println(k + " 的分词结果：");
        AtomicInteger i = new AtomicInteger();
        map.get(k).forEach(v -> {
            System.out.println("\t" + i.incrementAndGet() + " 、" + v);
        });
    });
}
public static void showMore(Map<String, Map<String, String>> map){
    map.keySet().forEach(k->{
        System.out.println(k + " 的分词结果：");
        AtomicInteger i = new AtomicInteger();
        map.get(k).keySet().forEach(a -> {
            System.out.println("\t" + i.incrementAndGet()+ " 、【"   + a + "】\t" + map.get(k).get(a));
        });
    });
}
public static void main(String[] args) {
    show(contrast("我爱楚离陌"));
    showMore(contrastMore("我爱楚离陌"));
}

运行结果如下：

********************************************
word分词器 的分词结果：
	1 、我 爱 楚离陌 
Stanford分词器 的分词结果：
	1 、我 爱 楚 离陌 
	2 、我 爱 楚离陌 
Ansj分词器 的分词结果：
	1 、我 爱 楚离 陌 
	2 、我 爱 楚 离 陌 
HanLP分词器 的分词结果：
	1 、我 爱 楚 离 陌 
smartcn分词器 的分词结果：
	1 、我 爱 楚 离 陌 
FudanNLP分词器 的分词结果：
	1 、我 爱楚离陌
Jieba分词器 的分词结果：
	1 、我爱楚 离 陌 
Jcseg分词器 的分词结果：
	1 、我 爱 楚 离 陌 
MMSeg4j分词器 的分词结果：
	1 、我爱 楚 离 陌 
IKAnalyzer分词器 的分词结果：
	1 、我 爱 楚 离 陌 
********************************************

********************************************
word分词器 的分词结果：
	1 、【全切分算法】	我 爱 楚离陌 
	2 、【双向最大最小匹配算法】	我 爱 楚离陌 
	3 、【正向最大匹配算法】	我 爱 楚离陌 
	4 、【双向最大匹配算法】	我 爱 楚离陌 
	5 、【逆向最大匹配算法】	我 爱 楚离陌 
	6 、【正向最小匹配算法】	我 爱 楚离陌 
	7 、【双向最小匹配算法】	我 爱 楚离陌 
	8 、【逆向最小匹配算法】	我 爱 楚离陌 
Stanford分词器 的分词结果：
	1 、【Stanford Chinese Treebank segmentation】	我 爱 楚离陌 
	2 、【Stanford Beijing University segmentation】	我 爱 楚 离陌 
Ansj分词器 的分词结果：
	1 、【BaseAnalysis】	我 爱 楚 离 陌 
	2 、【IndexAnalysis】	我 爱 楚 离 陌 
	3 、【ToAnalysis】	我 爱 楚 离 陌 
	4 、【NlpAnalysis】	我 爱 楚离 陌 
HanLP分词器 的分词结果：
	1 、【NLP分词】	我 爱 楚 离 陌 
	2 、【标准分词】	我 爱 楚 离 陌 
	3 、【N-最短路径分词】	我 爱 楚 离 陌 
	4 、【索引分词】	我 爱 楚 离 陌 
	5 、【最短路径分词】	我 爱 楚 离 陌 
	6 、【极速词典分词】	我 爱 楚 离 陌 
smartcn分词器 的分词结果：
	1 、【smartcn】	我 爱 楚 离 陌 
FudanNLP分词器 的分词结果：
	1 、【FudanNLP】	我 爱楚离陌
Jieba分词器 的分词结果：
	1 、【SEARCH】	我爱楚 离 陌 
	2 、【INDEX】	我爱楚 离 陌 
Jcseg分词器 的分词结果：
	1 、【简易模式】	我 爱 楚 离 陌 
	2 、【复杂模式】	我 爱 楚 离 陌 
MMSeg4j分词器 的分词结果：
	1 、【SimpleSeg】	我爱 楚 离 陌 
	2 、【ComplexSeg】	我爱 楚 离 陌 
	3 、【MaxWordSeg】	我爱 楚 离 陌 
IKAnalyzer分词器 的分词结果：
	1 、【智能切分】	我 爱 楚 离 陌 
	2 、【细粒度切分】	我 爱 楚 离 陌 
********************************************

完整代码看这里

可能感兴趣的文章

• 提升你的Java应用性能：改善数据处理
• Google宣布下一代Android系统——KitKat
• 115个Java面试题和答案——终极列表（上）
• 全文检索引擎Solr系列——Solr核心概念、配置文件
• 为什么不允许代码里出现“魔数”
• Java常用排序算法/程序员必须掌握的8大排序算法
• 八成Java开发者解答不了的问题
• Java Main如何被执行？
• Java I/O 模型的演进
• Java8 Top Tips

人们常常说数据如金，可是，能被利用起的数据，才是“金”。而互联网的数据，常常以日志的媒介的形式存在，并需要从中提取其中的”数据”。

从这些数据中，我们可以做用户画像（每个用户都点了什么广告，对哪些开源技术感兴趣），安全审计，安全防护（如果1小时内登录请求数到达一定值就报警），业务数据统计（如开源中国每天的博客数是多少，可视化编辑格式和markdown格式各占比例是多少）等等。

之所以能做这些，是因为用户的所有的行为，都将被记录在nginx日志中或其它web服务器的日志中。日志分析要做的就是将这些日志进行结构化，方便我们的业务人员快速查询。日志分析平台要做的就是这些。

说完这些，你是不是觉得日志分析平台很难做，需要十人的团队加班几个月才能完成？

自从有了Elasticsearch、Logstash、Kibana，俗称ELK，小公司也可以很轻松地做日志分析了。说白了，1天几G的日志，ELK完全可以吃得消。就像标题说的，只需要1个人半小时就可以搭建好了。前提是你已经熟悉了Ansible。下文也假设你已经熟悉Anbile，如果不熟悉可以看看我的另一篇文章： Puppet，Chef，Ansible的共性

本文目的就是教你如何在搭建一个日志分析平台的雏形。有了这个雏形，你可以慢慢迭代出更强大，更适合你业务的日志分析平台。同时，提供可执行的源代码： OSC-AdCenter

简单日志分析架构图

我做了简化，架构图中的每个组件都可以分别放到不同的机器。这里简单介绍下这些你组件：

• your app：你的应用，我们的源码中，把这个给省略了
• Openresty：基于Nginx的Web开发平台，你可以想像它基于Nginx做了很多扩展，类似淘宝的Tengine。为什么我们不直接使用Nginx呢？因为在Openresty上，我们可以做更多事情。
• Logstash：日志收集，结构化数据后，push到Elasticsearch中，基于JRuby。可使用其它日志收集工具替代，比如 Beats
• Elasticsearch：分布式搜索引擎，基于Lucene
• Kibana：用于可视化数据，基于NodeJs

日志分析平台开发所需要工具

• Ansible 2.0+：简单的自动化配置工具，运维工具。 关于自动化配置还有什么好说的呢？
• Vagrant：操作系统虚拟化工具，开发时使用。如果没有听过，Docker总听过吧。这家伙就和Docker完全类似的功能，也早于Docker出现。
• 一个简单的支持yml格式高亮的文本编辑器，比如Atom
• 自行下载JDK8: jdk-8u66-linux-x64.tar.gz放到项目路径： provision/roles/jdk8/files/jdk-8u66-linux-x64.tar.gz P.S. 抱歉这个的确需要你自己下。
• 什么？不用写代码吗？的确不用需要写。如果你要扩展这个雏形就会需要写一些脚本。

启动一台服务器

因为我们需要在本地开发好以后，再部署到生产环境，所以，我们需要一台服务器用来做实验。用Vagrant可以在你的开发机上虚拟化一台。clone 下 OSC-AdCenter后，进入项目目录执行： Vagrant up

文件Vagrantfile有描述这台机器的配置：

Vagrant.configure(2) do |config|

  ANSIBLE_RAW_SSH_ARGS = []
  machine_box = "trusty-server-cloudimg-amd64-vagrant-disk1"
  machine_box_url = "https://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"

  config.vm.define "oscadcenter" do |machine|
    machine.vm.box = machine_box
    machine.vm.box_url = machine_box_url
    machine.vm.hostname = "oscadcenter"
    machine.vm.network "private_network", ip: "192.168.4.10" ##指定这台机器的IP，只能宿主机能访问
    machine.vm.provider "virtualbox" do |node|
        node.name = "oscadcenter"
        node.memory = 4048
        node.cpus = 2
    end
   end

end

更多关于Vagrantfile： https://www.vagrantup.com/docs/vagrantfile/

Vagrant机器的默认账号密码都是: vagrant，所以你可以使用 ssh vagrant@192.168.4.10登录这台机器。也可以使用vagrant命令登录，在Vagrantfile所在目录下执行： vagrant ssh oscadcenter。

部署日志分析平台

在你的开发机上，安装好ansible：

服务器准备好了，我们只需要一条命令就可以部署OSC-AdCenter了：

ansible-playbook ./provision/playbook.yml  -i ./provision/inventory  -u vagrant -k

然后输入ssh登录密码： vagrant。

简单说明：

• ansible-playbook是ansible的一个命令
• ./provision/playbook.yml是描述你的服务器配置的文本，你可以想像成所有的部署脚本都写在这个文件中
• ./provision/inventory是服务器在playbook在的host与ip的映射表，比如playbook中这么写：
  

  ---
  - hosts: adcenter

  
  那么，inventory文件就是这样的：

[adcenter]
192.168.4.10

具体请看文档： http://docs.ansible.com/ansible/intro_inventory.html

• -u vagrant -k表示使用vagrant账号ssh登录目标机器

部署的这个过程，要看你的网速和elastic源的提供速度，可能会很漫长。参考时长为半小时。建议执行部署后，做些别的事情，比如午休。

测试部署是否成功

1. 打开Elasticsearch http://192.168.4.10:9200/_plugin/head/可看到界面：
2. 打开Kibana http://192.168.4.10:5601可看到界面：
3. 1. 打开各种浏览器，输入url： http://192.168.4.10/1.gif?account=oschina&e=pv&p=p233444&url=www.oschina.net&title=学习&sh=1200&sw=800&cd=400&lang=en，然后可在Elasticsearch中和kibana中看到相应的数据

我使用Chrome访问了两次url，再使用Safari访问了一次。就这样，Elasticsearch中出现了3条数据，而Kibana中我们可统计出，过去4小时中，Chrome占了2/3，而Safari占 1/3。

部署过程都执行了什么？

从部署脚本的入口 ./provision/playbook.yml看:

- hosts: analysis
  sudo: yes
  vars_files:
    - ./vars/base-env.yml
    - ./vars/analysis-logstash.yml

  roles:
    - common # 执行一些基础工作
    - openresty # 安装openresty
    - {role: "analysis-openresty-conf",   nginx_server_conf: "analysis.conf"} # 配置openresty
    - jdk8 # 安装jdk8，并设置JAVA_HOME到 /etc/profile中
    - ansible-role-elasticsearch  #安装 es
    - ansible-role-kibana-4 # 安装kibana4
    - ansible-logstash # 安装logstash

这里的ELK的role都是从Ansible 的 Galaxy上download下来的。

然后呢？

1. 学习Kibana的查询语法，根据业务需求来统计分析日志。
2. 对当前的日志分析平台实施监控，哪天系统挂了，你都不知道。
3. 与现在有的系统结合。
4. 解决当单个Elasticsearch，特别庞大时的扩容问题

最后

好吧，如果你不会Ansible，你半小时可能搞不定。所以，我说的半小时，其实并不科学。但是这也恰恰说明了使用的自动化配置的好处。我一个运维外行，利用Ansible两三天就搭建好了一个简单日志分析平台。

而且如果你要在生产环境使用这套系统，你只需要在线上准备一台干净的ubuntu服务器，修改inventory文件的IP就可以了。

现实中的日志分析平台一定不会这么简单的，本次教程，只是抛砖引玉。

如何在半小时搭建一个简单的日志分析平台？，首发于 文章 - 伯乐在线。

在这个巨变的时代，技术选型是个很难做决定的事情，而移动应用技术领域在几个巨头（Google，Facebook，Apple etc.）的带动下更是日新月异。所以说要选择一个适合业务需求并且匹配开发人员能力的技术方案并不是一件简单的事情。我也只是在移动开发上做过一点微小的工作，此处仅能抛个砖，希望各位有玉的大神尽管砸过来。

做移动应用开发，说起来技术方案不外乎HTML5（没错，做Mobile Web其实也算是一种移动应用）、Native（在Android上不管是用Java、Kotlin还是Scala，iOS上不管是用Objective-C还是Swift）和使用原生UI，用JavaScript来实现逻辑的诸如React Native一类的方案。除此之外，还有结合HTML5和Native的Hybird混合方案。不同的技术方案有着不同的适应场景，至于具体如何选择，接下来我简单地谈谈自己的理解。

1、HTML5

也就是Web App的方案。这种方案最大的优点在于“Write Once, Run Everywhere”，不管你是Android还是iOS，都可以用一套代码搞定，在国内的话还能对接微信公众号，给用户提供一个方便快捷的入口，并且还有版本升级容易的优势（毕竟服务器是受自己控制的）。但是这种方案的缺点也很明显——无法使用系统级API，只能做为一个临时的入口，用户很难留存，并且因为浏览器性能的原因，很难带来很好的用户体验。

所以说Web App的主要适用场景还是在于作为对非核心业务在移动端的入口补足，或者是作为用户轻量、低频使用的体验增强。

美团移动网站引导页

美团移动网站首页

美团的移动网页就是很典型的例子，主要还是提供给不经常使用的用户一个入口，网站内部还是在尽量引导用户下载使用客户端。

2、Hybird

Hybird是一种兼顾Native与HTML的开发模式，但根据实现的不同，还可以再细分为两种实现方案：

• 在Native App中使用WebView加载远端Web资源
• 使用Cordova/PhoneGap等框架通过WebView加载本地资源进行页面渲染

第一种方案其实已经应用得非常普遍了，很多应用的展示页面都是通过这种方式实现的。因为展示页面需要的正是能够轻易更换内容及布局的格式，并且这种纯展示的页面也并不需要复杂的动画与特效，使用Web页面是一个非常合适的解决方案。

而第二种方案前一段时间非常火，因为它在跨平台，在高效开发以及快速发布上有着明显的优势，毕竟Web内容只需要开发一次就可以在各个平台使用。而且将资源打包到本地也可以在一定程度上缓解从远端加载静态资源导致UI展示延迟的问题，并且还可以通过桥接Native和Web来调用一些Device的API。但其劣势也很明显，一是通过WebView执行代码效率较低，很难实现一些炫酷的效果，并且还存在不同设备的兼容性问题；二是如果想调用相关平台的API，需要针对平台单独进行开发，如果在应用中用到了大量的Device API，那么开发的效率将大大降低；三是很难应用到平台相关的新特性，比较难做出有特色的产品。

使用HTML页面来实现纯展示页面是非常推荐的一种方案。而Cordova/PhoneGap则更适用于对Mobile预算有限的公司、创业团队，或者对App进行快速的上线验证。

正好之前有个项目就用到了这种方案，为一家业务转型的零售商提供了使用一套基本代码来完成Android和iOS两个平台的App和微信公众号的相关页面的技术方案。

零售商Android应用零售商微信端

3、React Native

把React Native单独拿出来，是因为确实不能简单的将它分到其它任意一种方案里面去。React Native确实是最近最火的跨平台App解决方案了。它脱胎于React，因为React基于Virtual DOM来进行界面渲染，所以用Native的View来替换掉原本React的HTML DOM就顺理成章的引出了React Native的概念。

它与之前的跨平台方案有一个本质的区别，在于：其它方案都在追求写一次code解决所有平台的问题，而React Native的理念在于“Learn Once, Write Anywhere”。虽然大部分代码是平台无关的，但是平台相关的代码都需要单独实现，这虽然对跨平台带来了不便，但是引入的好处也是显而易见的，View层的部分通过原生组件实现，性能比其他WebView的方案不知道高到哪去了。而且React Native整套的逻辑代码都通过JavaScript实现，这样就让跨平台应用能够方便的复用逻辑代码。另外虽然React Native没有支持使用CSS来实现样式，但是提供了类似CSS的样式表支持，有过UI开发经验的人都能够非常快的上手。由于前端React也是非常的火，很多React社区的很多产出都可以在React Native上借鉴使用。

React Native对于没有复杂动画效果的一般应用来说不失为一个很好的解决方案。而且对于一些小型的企业级应用也是非常适用的。但是，React Native对于Android平台的支持度是不如iOS平台的，而且现有的非常成熟的应用也较少，所以说如果要在一些面向用户量很大，讲求用户体验的App中使用还是要慎重考虑的。

但是，其实Facebook已经在自家的App上用起来了，而且实测效果还是很好的。不过呢，人家毕竟是自家维护的，所以说真正要在项目上用可能还是得试了才知道效果。

facebook Androidfacebook iOS

4、原生应用

原生应用的开发真的是让人又爱又恨。爱在于你可以在它上面施展拳脚、使用新特性、实现炫酷的效果。而恨则在于它跨平台性几乎为零，除了资源外几乎没有可重用的东西，即使是相似架构上的逻辑你也得再实现一遍。使用原生开发，能够方便地添加动画效果，调用底层硬件，所有的限制仅仅是来自平台的限制。但是正常情况下需要对不同的平台搭配不同的开发人员，而且如果要追求良好的用户体验，整个应用的设计还得满足相应平台的设计规范，这不仅是对Dev的考验，也是对UX的考验。不过如果真的对App的质量有很高的要求，我觉得这一切的付出也还是都是值得的。

如果针对的是要求硬件性能、讲究动画效果、追求用户体验的应用，还是建议分平台单独设计，并且都使用原生的技术方案来实现。其实这也是目前市面上大部分企业做出的选择。

使用原生开发我个人还有一个观点，就是 设计上要尽量遵守原生应用的设计规范，如果想要一套设计通吃所有平台，最终只会搞一个不伦不类的应用出来。知乎算是国内在这方面做得比较好的应用了，也取得了不错的效果。

知乎

其实，在真正启动项目之前，在进行技术选型时，除了要考虑更符合业务的架构外，还要考虑开发人员的能力及技术栈。毕竟最后App还是由Dev们开发的。如果仅仅考虑业务而不考虑开发人员的技术能力来选择技术方案，不仅有一种钦定的感觉，而且最后往往坑到的还是自己。

我们常说：工具是死的，人是活的。考虑多种因素，在技术选型上做出更充分的考量，才是真正正确的选择。所以说又回到那句老话上：“It depends…”

浅谈移动应用的技术选型，首发于 文章 - 伯乐在线。

一个好的技术团队应该具备哪些特质？一个好的技术团队的leader应该怎样实施管理？技术和业务如何做到完美结合？这是来自天猫技术团队的经验，仅供参考。

前言

2012年，无线化大规模到来的前夕，淘宝成立了天猫团队，四年来天猫的不断发展离不开其背后技术团队强有力的支持。这样的一个技术团队，是怎样实施管理的？是怎样平衡完成需求和提升技术能力这两者之间的关系的？其核心竞争力是什么，怎样长期保持核心竞争力？

而作为天猫总架构师的何崚，作为天猫团队的技术领导者，在加入淘宝的十年来，由单纯只关心“技术指标”的“需求翻译机器”、“架构优化机器”，转变为从技术视角推动平台业务发展的业务架构师。在他的领导下，天猫技术团队立志“做全球最懂商业的技术团队”，不断锻炼“寻找技术和业务完美结合点的敏锐嗅觉”，保持“跨界”的核心竞争力。

那么，何崚的淘宝十年，其具体职责发生了哪些变化？对架构师的理解又是怎样一步一步加深的？作为技术领导者，应该将对公司业务和战略的认知放到一个什么样的位置？在实际工作中，如何体现技术和商业的深度结合？

带着这些问题，InfoQ采访了天猫总架构师何崚，一起来了解天猫技术团队的更多信息。

作者简介

何崚，天猫总架构师，阿里巴巴集团研究员。领导过天猫的平台架构团队，交易链路和行业开发团队，无线开发团队，阿里巴巴中文站的网站架构部。

目前的主要工作是带领团队推动天猫平台升级，拓展天猫业务的外延，包括垂直化，多终端化，智能化下的电商平台架构改造，电商平台和商家系统的供应链协同，天猫超市，天猫国际，天猫电器城等多个行业纵深技术系统的建设，消费者链路的交互升级，以及推进阿里电商架构委员会的相关工作。致力于构建驱动天猫业务高速发展的技术引擎，并尽情享受技术和商业的深度结合的思考和试错所带来的快乐。

1、阿里十年，我所理解的总架构师

2006年初，我加入阿里巴巴中文站技术部。最初，我负责B2B核心系统的开发工作，当时中文站正处于从B2B信息平台向B2B交易平台转变的业务高速增长期。我们意识到B2B交易是未来的方向，所以集中精力推进了服务商品化、店铺化、分阶段大额交易、安全风控、B2B物流及B2B采购等一系列促进平台业务升级的关键战役，并解决了业务发展过程中遇到的系统容量瓶颈以及单元化，研发效率工具化等架构治理问题。

在推进全站业务升级的过程中，我的思考方式发生了很大的转变，由单纯只关心“技术指标”的“需求翻译机器”、“架构优化机器”，转变为从技术视角推动平台业务发展的业务架构师。

2011年，阿里巴巴中文站从各个业务开发团队抽调骨干，成立架构部。我作为阿里巴巴中文站的总架构师，带领这个架构师团队，对全站业务进行了梳理，梳理出B2B核心的业务领域，构建出与之对应的服务化中心，与淘宝打通了基础数据服务，并对全站主要业务系统进行了服务化改造，为后来B2B的业务升级例如村淘、产业带、淘工厂等业务奠定了架构基础。

经过几年的沉淀，我对B2B业务及对应的产品技术体系已经非常熟悉了，但是我一直希望能了解面向消费者端的产品技术体系。

2012年初，我有幸加入天猫，负责天猫的平台架构部，带领天猫架构团队完成从C2C平台向B2C平台的升级。首先，在消费者链路方面，为了更好更快的支撑B2C的交易特点和模式我们构建了新的交易平台Tmallbuy；

其次，在商家链路方面，原先面向C类个人卖家的淘宝平台，越来越不能满足B类商家尤其是品牌商规模化入驻的诉求，尤其是在多渠道区域化运营方面，因此我们重点建设了大B平台和库存中心，弥补了天猫体系中缺失的仓储、库存、渠道及服务等环节，并对接了商家的供应链体系，有效支持了大牌招商入驻计划，提升了平台丰富度，同时使得品牌商的区域营销策略、供应链能力及服务能力在平台得以表达，提供比C2C平台更具确定性的消费者体验。

2013年，无线化大潮到来，我兼任天猫无线开发团队负责人，负责天猫客户端及手淘内天猫部分的开发，同时对原有面向PC的网站架构进行无线化升级，构建Dynative跨终端组件化开发方案，TWP无线活动营销工具等无线架构基础设施。

与此同时，天猫逐步进入行业精细化运营阶段，需要对平台进行全面的升级，我们构建了“行业中台”来快速支持天猫超市、天猫国际、天猫电器、天猫生鲜、天猫医药馆及企业采购等丰富多彩的业务，同时还将我们的关键产品技术能力输出给阿里其他BU和外部商家。

我的理解，总架构师的关键职责是落地技术战略，首先要参与到业务的战略方向、业务目标及关键战役的制定讨论过程中，然后梳理对应公司战略的平台升级方向，以及架构演进过程中关键的架构治理问题，制定对应业务战略的技术战略，最后带领全站架构师统筹架构规划并分解落地实现。

具体来说，第一要推进架构演进，带领全站架构师明确架构愿景，统一架构实施路线；第二要进行架构管控，制定架构规范，提供管控工具，使得大家在统一的方法论上协同推进，避免架构失控；第三要敏锐的识别平台升级的机会和关键架构痛点，发起重点架构升级项目。

2、天猫四年，技术团队步步为营

天猫的前身是淘宝商城，在最初业务高速增长的时候，为了快速支撑B2C业务在交易链路上的各种需求，淘宝商城和淘宝的体系是分开的，包括商品、交易、营销，搜索以及店铺等。

从2011年开始，当时天猫大商家规模化入驻，面向C类卖家的电商平台不能满足B类商家入驻的场景，需要补充天猫架构中缺失的仓储、库存、渠道、服务等供应链环节，并对接商家供应链，来帮助天猫完成大牌招商入驻计划，提升平台丰富度，同时也能让品牌商的供应链能力在平台得以表达，提供给消费者相比于淘宝平台更具确定性的消费体验。

因此在团队设计上，除了有团队支持电商链路核心的导购、营销、交易等产品，还有专门的团队负责构建C2C平台向B2C平台过程中缺失的面向B链路的产品技术体系。

2012年，无线化大规模到来的前夕，我们成立了天猫的无线开发团队，除了开发独立的天猫客户端以外，也负责开发手淘客户端内天猫部分的内容。

2013年，随着天猫业务进入行业精细化运营阶段，为了更好的支持行业业务团队开展业务，需要针对不同行业业态和用户心智构建相应的产品技术体系。我们按行业粒度成立了专门的行业开发团队，同时商品、交易、营销及搜索等关键业务系统和淘宝的对应系统也进行了深度的融合，大幅提升电商链路的研发效率。

2015年，我们团队引入了供应链领域运筹优化和机器学习的算法人才，从一开始只支持天猫超市的业务，逐步延展到可快速支撑天猫生鲜、天猫电器、天猫国际及企业采购等偏供应链业务的发展，同时我们也对外输出能力，支持集团内其他偏供应链的业务，如俪人购等。

2016年，我们的供应链产品技术体系开始对接第三方服务能力，来支持天猫汽车，天猫家装等重服务行业对行业特色服务的需求。

3、三大组织助力天猫

“做全球最懂商业的技术团队”

首先在组织架构设计上，为了高效支持业务，天猫技术团队采取了横纵结合的方式，既有偏横向的平台开发团队（例如交易平台），又有偏纵向的垂直行业开发团队。平台开发团队深入到电商交易链路做到极致，支持多行业多终端的业务需求。垂直行业开发团队则聚焦于挖掘不同行业的消费者心智，支持天猫的行业精细化运营战略。

同时我们设立了三个横向组织：

“架构师委员会”：是横向的架构治理组织，负责天猫技术发展过程中的关键技术决策，未来技术路线图，核心链路架构review和重点架构升级项目的推进。

“极客大学”：面向全体开发人员的培训组织，同时也设立了几个面向未来的课题组，让大家在这些场子里能够有充分的交流碰撞和提升。

“稳定性小组”：天猫业务链路平稳运转的守护神，包括日常紧急问题的快速发现及处理，双11等核心战役的备战，以及全链路压测、功能预演、全方位数据监控、单元化改造、电商链路上云等核心技术的突破。

在团队文化上，我们立志成为“做全球最懂商业的技术团队”，因此我们会鼓励技术同学加强对公司战略和业务目标的了解，通过各种形式积极参与业务目标和关键战役的讨论，要在日常的开发工作中更深入地去了解需求的场景和价值，这是天猫技术团队的立身之本。

同时为了更好的了解客户，我们制定了周密的商家拜访计划，制定商家地图，了解他们的诉求，并针对商家普遍反映的痛点问题制定对应的产品技术解决方案。

至于如何平衡完成需求和提升技术能力两者之间的关系，首先技术团队不仅仅是完成需求，我们不做“需求翻译机“，我们也会和业务同学一起讨论需求的合理性，搞清楚什么是当前最紧急的最有价值的需求。

从另一个角度说，如果技术同学不主动去研究业务和客户痛点，只是被动的去开发业务方提出的需求，早晚会把自己变成“需求实现机器”和“性能优化机器”。不思考业务，技术同学会变得越来越机械，逐步丧失创新的灵感，他的工作迟早会被人工智能取代，自己的成就感也很差。

相反，主动去研究业务，便可以更好的整合各类需求，加以抽象总结，沉淀符合业务趋势的产品，从而更好的支持业务发展，甚至可以给到业务新的灵感。

过去我们总说技术推动业务，事实上业务同样也是技术突破的原动力，给技术创新带来无限的可能性，天猫技术团队的很多技术突破，都是在实现需求的过程中落地的，例如在天猫超市业务发展过程中沉淀下来的供应链平台、B2C的营销平台、供应链算法平台；在提升消费者体验目标下逐步发展和完善起来的推荐平台、互动平台及售后服务平台；在赋能商家赋能小二过程中成长起来的快速活动平台、数据化运营平台及内容平台；在行业化发展及各类大促玩法中沉淀下来的各类基础产品如资金平台、渠道库存、交易预售模式、秒杀平台等。

4、技术创新与商业结合

打造消费者体验的新生态

天猫技术团队的优势是我们的技术同学具备商业视野，而很多技术创新恰恰是由商业推动的，因此天猫技术同学经常能找到技术和商业的完美结合点。

技术同学在和业务同学一起讨论业务方向的过程中，能够不断找到技术创新和商业结合的点子，并输入给业务同学。当看到自己的点子转化成用户口碑和商业指标提升的时候，技术同学会获得不一样的成就感，这种成就感有时会比单纯的系统技术指标的提升更强烈，会激发他们不断思考业务，寻找技术和商业结合的创新方式，形成良性循环。

天猫不能永远以电子货架的方式呈现在消费者面前，天猫的技术同学也一直在探索和思考更加丰富友好的交互形式。我们想，如果能将电商属性和游戏的魅力进行结合，也许能跳出传统卖货的思维，成为商家和消费者更友好的互相触达的新通道。

前年的双11前夕，我们推出了互动游戏平台，第三方开发者通过我们提供的SDK开发的具备电商属性的小游戏，能够接入到商家在PC端和无线端的店铺中，通过这些精心设计的互动游戏，消费者能更深入地了解品牌，商家也能更加深入地了解自己用户的诉求，同时，第三方开发者也能获得可观的收益。

双11我们收到了大量的第三方作品，以店铺组件的方式提供给商家做店铺装修，双11期间，出乎意料的收到了用户的热烈反响，成为当年双11的亮点。去年，我们推出双11互动晚会，也收到了超出预期的反响。

我们预判未来一两年，现有文字图片为主的交互形式将发生重大变革，VR/AR,3D（图片、建模）、手势、动画、语音、视频、全景等新的交互形式，不仅仅会出现在线上活动互动和品牌营销领域，更会出现在电商平台的消费者主链路中。

同时，我们希望通过今年的天猫互动创意大赛，挑选出行业内优秀的创新技术，与优秀的开发团队建立合作关系，联合产学研，共同打造电商领域消费者体验创新的生态环境。

5、跨界——天猫技术团队的核心竞争力

天猫技术团队的核心竞争力，是一种跨界能力，是一种寻找技术和业务完美结合点的敏锐嗅觉，是技术驱动业务创新的践行能力。

在团队文化上，我们提出了“做全球最懂商业的技术团队”的口号，与阿里其他技术团队相比，我们没有那么多底层技术专家，但我们有大量的业务架构师。这些业务架构师对于电商模式转型，客户价值探索、行业运营赋能方面有着强烈的热情，是能够将最合适的技术与商业产生化学反应的跨界人才，他们尝试将商业行为结构化，尝试找到提升商业效率的函数，是真正能够释放数据生产力的推手。

当我们发现新技术成为我们业务创新的催化剂的时候，我们会迅速的补全我们的能力短板。例如当我们尝试使用人工智能来突破供应链效率、运营效率及售后体验瓶颈时，我们会在全世界寻找并引进相关的人才，同时我们原有的工程同学也自发的补充深度学习技术，并尝试在项目中应用这些技术。

过去很多互联网创新是由产品经理，甚至完全不懂技术的业内人士去推动的，有了个点子，找了几个写APP的工程师就开搞了，我认为今后这样由0到1的机会越来越少。我坚信未来的创新是属于跨界人才的，既是行业专家又有极强的技术实践能力的业务架构师，将是推动商业创新的主力军。事实上目前天猫的很多商业创新最初都是由业务架构师驱动的。

天猫技术团队未来的努力方向，我个人认为在平台端，需要全面推动由基于商业规则的业务系统，向基于机器学习的专家系统的升级；在商家端，则是沿着电商平台的上下游，向上向下对接产业链各角色的系统，围绕天猫精细化行业运营和赋能商家的战略，将自己领先的电商平台能力和大数据处理能力提供给商家，降低商业活动中的信息获取成本、人力成本、营销成本、采购成本及物流成本；

同时在消费者端，要采用VR/AR、3D（图片、建模）、手势、动画、语音、视频、全景等交互形式革新现有的货架式消费者链路，拓展电商平台卖货以外的能力。

6、做全球最懂商业的技术团队

天猫过去是提供给商家和消费者在线交易的流量营销平台，不碰货，消费者下完单后就由商家去履行，这种模式轻便灵活，但是平台在品控和服务确定性方面面临较大的挑战。

为了给消费者提供更好的体验，我们在一些特定的品类上，也深入到供应链体系，随着天猫超市、天猫电器等品类的发展，相应的产品技术体系也在快速的发展中。

控制供应链，深入到从供货到履行的环节，保证货品的品质和服务的确定性，提供给消费者最好的体验。

通过大数据把消费者的需求趋势提前提供给商家，同时和商家完成供应链协同计划，提升库存周转率，降低商家的供应链成本。

对于一些重服务行业，我们接入第三方的优质服务，将这些服务打包成产品提供给商家，同时在消费者端表达出来，通过大数据管控服务履行，与之前的实物供应链不同，这实际上在打造一条全新的服务供应链。

为了推进业务在这些领域的创新和发展，技术团队需要更深入地了解行业、了解业务、了解客户。

在组织架构上，我们成立了专门的供应链研发团队，引进了一些供应链领域和机器学习算法领域的专家，将我们现有的业务系统融合机器学习，深度学习，运筹优化，自然语言处理，图像识别等技术，同时建立我们的行业数据库，给我们的业务系统带来更多智能化的元素。

在团队文化上，我们提出了“做全球最懂商业的技术团队”的口号，鼓励技术同学更积极主动的和业务同学去交流，组织行业专家普及供应链专业知识，同时开展了商家调研计划，和天猫商家建立了产品技术的合作关系，了解他们在所处行业商业竞争中的诉求，并将天猫在电商平台能力、大数据处理能力及运筹优化的能力打包成产品和服务提供给商家，提升他们的商业竞争力。

7、技术领导人应对公司业务和战略有怎样的认知

我一直坚信，天猫的可持续发展，需要两个增长引擎，平台运营能力和产品技术能力。

过去10年，伴随互联网技术的发展，我们构建了打通在线交易支付配送的电商平台，然后不断修炼平台运营能力，在商业规模上不断突破，流量、买卖家数、商品丰富度及订单量都连创新高，双11更是成为全球消费者狂欢的节日。

从现在的商业和技术发展态势来看，新一轮技术商业化的契机已经到来。如何抓住契机，让它成为天猫新一轮增长的引擎，如何把技术创新实实在在转换成消费者体验提升，转换成商家商业能力的提升，如何用技术创新促进产业升级，是摆在技术团队面前的挑战，也是技术领导者日常工作中要解决的问题。

这些思考需要转换成公司战略制定的重要输入。因此，技术领导人不仅仅要了解公司的业务和战略，更要深入地参与到公司的业务和战略的决策和实施过程中。目前，天猫技术团队负责人也是“天猫班委”之一，参与天猫的战略决策和战役制定。

8、如何解读“好的公司，技术就是商业，商业就是技术”

技术和商业深度结合方面：

第一步：明确技术平台升级的方向

通过解读业务数据，搜集行业信息，建立产学研链接，加深对商家，对行业的了解。解读信息的过程中，寻找机会，拓展商业外延，提出对应解决方案。通过处理并解读业务数据，你能发现很多商业机会。

例如，通过对不同地区不同人群偏好趋势的分析，你能发现商家的运作效率的短板，能给出货品在时间和空间上的最佳分布，能发现不合时宜的营销行为，数据中隐藏着很多的商业秘密。这样，一整套解决现有问题、提升商业效率的解决思路就逐渐出现了。

如果你没有这些数据，你最好要想办法获取这样的数据。为了更好的解读数据，业务架构师要不断自我驱动，学习行业知识，更深入地去了解消费者、商家和对应的行业。

过去天猫业务架构师的专长是互联网营销思维，对于消费者相对比较了解，但是对于商家而言，只是改进商家的线上渠道营销效率，并不能足以使商家，尤其是传统品牌商的商业能力发生根本的提升。很多品牌商在品牌渗透率、会员营销、生产计划、采购成本、仓储物流成本及渠道成本等各个领域都会自己的目标和挑战。

而阿里在互联网营销平台上积累的IT能力和大数据能力以及互联网思维的方法论，同样也可以应用于那些领域，要想发现这些商业机会，关键就是如何提升业务架构师的视野。

通过拜访商家，了解商家在全链路上的问题和诉求，同时和产学研建立合作关系，以及更深入地搜集行业的信息，逐渐就会建立起自己的行业知识库和商业判断。然后，寻找天猫战略目标和这些商业机会的结合点，提出对应解决方案，逐步拓展天猫的业务外延。

第二步：积极推动变革

向上向下寻求支持，向上寻求业务方和管理层的支持，向下寻求团队的一致认同，成为团队的主要目标。并将自己的想

法变成关键业务战役，让相关的技术团队、产品团队及业务团队都能够全力参与进来(ALLIN!)。

第三步：小步迭代，不断试错，不断修正目标。

目前我正在全力推进天猫平台3.0升级,尤其是完成由基于商业规则的业务系统向基于机器学习的专家系统的转变！

电商平台的商业能力受限于运营团队的运作效能，而我个人认为天猫技术团队未来的努力方向，是通过大数据更了解消费者，提供给消费者更个性化更专业的服务，通过革命性的交互技术，改变传统电商货架，提供消费者更真实更友好的体验。

同时也通过大数据分析产业的机会，通过技术手段链接产业上下游的各个角色，使得各角色能在统一的经过运筹优化的供应链计划上高效协同，降低商业的成本，帮助产业升级。

文章出处：InfoQ

本篇主要讲解如何使用直接内存（堆外内存），并按照下面的步骤进行说明：

相关背景-->读写操作-->关键属性-->读写实践-->扩展-->参考说明

希望对想使用直接内存的朋友，提供点快捷的参考。

数据类型

下面这些，都是在使用 DirectBuffer中必备的一些常识，暂作了解吧！如果想要深入理解，可以看看下面参考的那些博客。

基本类型长度

在Java中有很多的基本类型，比如：

• byte，一个字节是8位bit，也就是1B
• short，16位bit，也就是2B
• int，32位bit，也就是4B
• long, 64位bit，也就是8B
• char，16位bit，也就是2B
• float，32位bit，也就是4B
• double，64位bit，也就是8B

不同的类型都会按照自己的位数来存储，并且可以自动进行转换提升。
byte、 char、 short都可以自动提升为 int，如果操作数有 long，就会自动提升为 long， float和 double也是如此。

大端小端

由于一个数据类型可能有很多个字节组成的，那么它们是如何摆放的。这个是有讲究的：

• 大端：低地址位 存放 高有效字节
• 小端：低地址位 存放 低有效字节

举个例子，一个 char是有两个字节组成的，这两个字节存储可能会显示成如下的模样，比如字符 a:

低地址位    高地址位
大端；        00              96
小端：        96              00

String与new String的区别

再说说 "hello"和 new String("hello")的区别：

如果是 "hello"，JVM会先去共享的字符串池中查找，有没有 "hello"这个词，如果有直接返回它的引用；如果没有，就会创建这个对象，再返回。因此， "a"+"b"相当于存在3个对象，分别是 "a"、 "b"、 "ab"。

而 new String("hello")，则省去了查找的过程，直接就创建一个 hello的对象，并且返回引用。

读写数据

在直接内存中，通过 allocateDirect(int byte_length)申请直接内存。这段内存可以理解为一段普通的基于 Byte的数组，因此插入和读取都跟普通的数组差不多。

只不过提供了基于不同数据类型的插入方法，比如：

• put(byte) 插入一个byte
• put(byte[]) 插入一个byte数组
• putChar(char) 插入字符
• putInt(int) 插入Int
• putLong(long) 插入long

等等….详细的使用方法，也可以参考下面的图片：

对应读取数据，跟写入差不多：

注意所有没有index参数的方法，都是按照当前position的位置进行操作的。

下面看看什么是position，还有什么其他的属性吧！

基本的属性值

它有几个关键的指标：

mark-->position-->limit-->capacity

另外,还有 remaining=limit-position。

先说说他们的意思吧！

当前位置——position

position是当前数组的指针，指示当前数据位置。举个例子：

ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
buffer.putChar('a');
System.out.println(buffer);
buffer.putChar('c');
System.out.println(buffer);
buffer.putInt(10);
System.out.println(buffer);

由于一个char是2个字节，一个Int是4个字节，因此position的位置分别是:

2,4,8

注意，Position的位置是插入数据的当前位置，如果插入数据，就会自动后移。
也就是说，如果存储的是两个字节的数据，position的位置是在第三个字节上，下标就是2。

java.nio.DirectByteBuffer[pos=2 lim=1024 cap=1024]
java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
java.nio.DirectByteBuffer[pos=8 lim=1024 cap=1024]

• position可以通过position()获得，也可以通过position(int)设置。

//position(int)方法的源码
public final Buffer position(int newPosition) {
        if ((newPosition > limit) || (newPosition < 0))
            throw new IllegalArgumentException();
        position = newPosition;
        if (mark > position) mark = -1;
        return this;
    }

注意：position的位置要比limit小，比mark大

空间容量——capacity

capacity是当前申请的直接内存的容量，它是申请后就不会改变的。

• capacity则可以通过capacity()方法获得。

限制大小——limit

我们可能想要改变这段直接内存的大小，因此可以通过一个叫做Limit的属性设置。

• limit则可以通过limit()获得，通过limit(int)进行设置。

注意limit要比mark和position大，比capacity小。

//limit(int)方法的源码
public final Buffer limit(int newLimit) {
        if ((newLimit > capacity) || (newLimit < 0))
            throw new IllegalArgumentException();
        limit = newLimit;
        if (position > limit) position = limit;
        if (mark > limit) mark = -1;
        return this;
    }

标记位置——mark

mark，就是一个标记为而已，记录当前的position的值。常用的场景，就是记录某一次插入数据的位置，方便下一次进行回溯。

• 可以使用 mark()方法进行标记，
• 使用 reset()方法进行清除，
• 使用 rewind()方法进行初始化

  //mark方法标记当前的position,默认为-1
  public final Buffer mark() {
  mark = position;
  return this;
  }
  //reset方法重置mark的位置，position的位置，不能小于mark的位置，否则会出错
  public final Buffer reset() {
  int m = mark;
  if (m < 0)
      throw new InvalidMarkException();
  position = m;
  return this;
  }
  //重置mark为-1.position为0
  public final Buffer rewind() {
  position = 0;
  mark = -1;
  return this;
  }

  使用案例

  ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
  buffer.putChar('a');
  buffer.putChar('c');
  System.out.println("插入完数据 " + buffer);
  buffer.mark();// 记录mark的位置
  buffer.position(30);// 设置的position一定要比mark大，否则mark无法重置
  System.out.println("reset前 " + buffer);
  buffer.reset();// 重置reset ，reset后的position=mark
  System.out.println("reset后 " + buffer);
  buffer.rewind();//清除标记，position变成0，mark变成-1
  System.out.println("清除标记后 " + buffer);

  可以看到如下的运行结果：

  插入完数据 java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
  reset前 java.nio.DirectByteBuffer[pos=30 lim=1024 cap=1024]
  reset后 java.nio.DirectByteBuffer[pos=4 lim=1024 cap=1024]
  清除标记后 java.nio.DirectByteBuffer[pos=0 lim=1024 cap=1024]

剩余空间——remaing

remaing则表示当前的剩余空间：

  public final int remaining() {
        return limit - position;
    }

读写实践

写操作主要就是按照自己的数据类型，写入到直接内存中，注意每次写入数据的时候，position都会自动加上写入数据的长度，指向下一个该写入的起始位置：

下面看看如何写入一段byte[]或者字符串：

ByteBuffer buffer = ByteBuffer.allocateDirect(10);
byte[] data = {1,2};
buffer.put(data);
System.out.println("写byte[]后 " + buffer);
buffer.clear();
buffer.put("hello".getBytes());
System.out.println("写string后 " + buffer);

输出的内容为:

写byte[]后 java.nio.DirectByteBuffer[pos=2 lim=10 cap=10]
写string后 java.nio.DirectByteBuffer[pos=5 lim=10 cap=10]

读的时候，可以通过一个外部的 byte[]数组进行读取。由于没有找到直接操作直接内存的方法: 因此如果想在JVM应用中使用直接内存，需要申请一段堆中的空间，存放数据。

如果有更好的方法，还请留言。

ByteBuffer buffer = ByteBuffer.allocateDirect(10);
buffer.put(new byte[]{1,2,3,4});
System.out.println("刚写完数据 " +buffer);
buffer.flip();
System.out.println("flip之后 " +buffer);
byte[] target = new byte[buffer.limit()];
buffer.get(target);//自动读取target.length个数据
for(byte b : target){
    System.out.println(b);
}
System.out.println("读取完数组 " +buffer);

输出为

刚写完数据 java.nio.DirectByteBuffer[pos=4 lim=10 cap=10]
flip之后 java.nio.DirectByteBuffer[pos=0 lim=4 cap=10]
1
2
3
4
读取完数组 java.nio.DirectByteBuffer[pos=4 lim=4 cap=10]

常用方法

上面的读写例子中，有几个常用的方法：

clear()

这个方法用于清除mark和position，还有limit的位置：

public final Buffer clear() {
        position = 0;
        limit = capacity;
        mark = -1;
        return this;
    }

flip()

这个方法主要用于改变当前的Position为limit，主要是用于读取操作。

   public final Buffer flip() {
        limit = position;
        position = 0;
        mark = -1;
        return this;
    }

compact()

这个方法在读取一部分数据的时候比较常用。
它会把当前的Position移到0，然后position+1移到1。

    public ByteBuffer compact() {
        int pos = position();
        int lim = limit();
        assert (pos <= lim);
        int rem = (pos <= lim ? lim - pos : 0);

        unsafe.copyMemory(ix(pos), ix(0), rem << 0);
        position(rem);
        limit(capacity());
        discardMark();
        return this;
    }

比如一段空间内容为:

123456789

当position的位置在2时，调用compact方法，会变成：

345678989

isDirect()

这个方法用于判断是否是直接内存。如果是返回true，如果不是返回false。

rewind()

这个方法用于重置mark标记：

 public final Buffer rewind() {
        position = 0;
        mark = -1;
        return this;
    }

参考

1  Java基本数据类型
2  Java中大端与小端

相关文章

• 谈谈Java内存管理
• Java内存使用系列一：Java 对象的内存占用
• Java内存问题
• Java内存管理原理及内存区域详解
• 内存不足：杀死进程还是牺牲子进程
• Java应用程序中的内存泄漏及内存管理
• Java高速、多线程虚拟内存
• 危险代码：如何使用Unsafe操作内存中的Java类和对象—Part4
• 危险代码：如何使用Unsafe操作内存中的Java类和对象—Part3
• 危险代码：如何使用Unsafe操作内存中的Java类和对象—Part2

由于之前在阿里云上部署的 Docker 1.12.2的Swarm集群没能正常展示出其所宣称的Routing mesh和VIP等功能，为了满足项目需要，我们只能转向另外一种容器集群管理和服务编排工具 Kubernetes。

注：之前Docker1.12集群的Routing mesh和VIP功能失效的问题，经过在github上 与Docker开发人员的沟通，目前已经将问题原因缩小在阿里云的网络上面，目前看是用于承载vxlan数据通信的节点4789 UDP端口不通的问题，针对这个问题，我正在通过阿里云售后工程师做进一步沟通，希望能找出真因。

Kubernetes(以下称k8s)是Google开源的一款容器集群管理工具，是Google内部工具Borg的“开源版”。背靠Google这个高大上的亲爹，k8s一出生就吸引了足够的眼球，并得到了诸多知名IT公司的支持。至于Google开源k8s的初衷，美好的说法是Google希望通过输出自己在容器领域长达10多年的丰富经验，帮助容器领域的开发人员和客户提升开发效率和容器管理的档次。但任何一种公司行为都会有其背后的短期或长期的商业目的，Google作为一个商业公司也不会例外。Google推出k8s到底为啥呢？众说纷纭。一种说法是Google通过k8s输出其容器工具的操作和使用方法、API标准等，为全世界的开发人员使用其公有容器预热并提供“零门槛”体验。

k8s目前是公认的最先进的容器集群管理工具，在1.0版本发布后，k8s的发展速度更加迅猛，并且得到了容器生态圈厂商的全力支持，这包括 coreos、 rancher等，诸多提供公有云服务的厂商在提供容器服务时也都基于k8s做二次开发来提供基础设施层的支撑，比如华为。可以说k8s也是Docker进军容器集群管理和服务编排领域最为强劲的竞争对手。

不过和已经原生集成了集群管理工具swarmkit的Docker相比，k8s在文档、安装和集群管理方面的体验还有很大的提升空间。k8s最新发布的 1.4版本就是一个着重在这些方面进行改善的版本。比如1.4版本对于Linux主要发行版本Ubuntu Xenial和Red Hat centos7的用户，可以使用熟悉的apt-get和yum来直接安装Kubernetes。再比如，1.4版本引入了kubeadm命令，将集群启动简化为两条命令，不需要再使用复杂的kube-up脚本。

但对于1.4版本以前的1.3.x版本来说，安装起来的赶脚用最近流行的网络词汇来形容就是“蓝瘦，香菇”，但有些时候我们还不得不去挑战这个过程，本文要带大家了解的就是利用 阿里云国内区的ECS主机，在 Ubuntu 14.04.4操作系统上安装 k8s 1.3.7版本的方法和安装过程。

零、心理建设

由于k8s是Google出品，很多组件与google是“打断了骨头还连着筋”，因此在国内网络中安装k8s是需要先进行心理建设的^_^，因为和文档中宣称的k8s 1.4版的安装或docker 1.12.x的安装相比，k8s 1.3.7版本的安装简直就是“灾难级”的。

要想让这一过程适当顺利一些，我们必须准备一个“加速器（你懂的）”。利用加速器应对三件事：慢、断和无法连接。

• 慢：国内从github或其他国外公有云上下东西简直太慢了，稍大一些的文件，通常都是几个小时或是10几个小时。
• 断：你说慢就算了，还总断。断了之后，遇到不支持断点续传的，一切还得重来。动不动就上G的文件，重来的时间成本是我们无法承受的。
• 无法连接：这个你知道的，很多托管在google名下的东西，你总是无法下载的。

总而言之，k8s的安装和容器集群的搭建过程是一个“漫长”且可能反复的过程，需要做好心理准备。

BTW，我在安装过程使用的 网友 noah_昨夜星辰推荐的 多态加速器，只需配置一个http_proxy即可，尤其适合服务器后台加速，非常方便，速度也很好。

一、安装模型

k8s的文档不可谓不丰富，尤其在k8s安装这个环节，k8s提供了针对各种云平台、裸机、各类OS甚至各类cluster network model实现的 安装文档，你着实得费力挑选一个最适合自己情况的。

由于目前国内阿里云尚未提供 Ubuntu 16.04LTS版本虚拟机镜像（通过apt-get install可直接安装最新1.4.x版本k8s），我们只能用ubuntu 14.04.x来安装k8s 1.3.x版本，k8s 1.4版本使用了systemd的相关组件，在ubuntu 14.04.x上手工安装k8s 1.4难度估计将是“地狱级”的。网络模型实现我选择coreos提供的 flannel，因此我们需要参考的是由国内浙大团队维护的 这份k8s安装文档。浙大的这份安装文档针对的是k8s 1.2+的，从文档评分来看，只是二星半，由此推断，完全按照文档中的步骤安装，成功与否要看运气^_^。注意该文档中提到：文档针对ubuntu 14.04是测试ok的，但由于ubuntu15.xx使用systemd替代upstart了，因此无法保证在ubuntu 15.xx上可以安装成功。

关于k8s的安装过程，网上也有很多资料，多数资料一上来就是下载xxx，配置yyy，install zzz，缺少一个k8s安装的总体视图。与内置编排引擎swarmkit的单一docker engine的安装不同，k8s是由一系列核心组件配合协作共同完成容器集群调度和服务编排功能的，安装k8s实际上就是将不同组件安装到承担不同角色的节点上去。

k8s的节点只有两种角色：master和minion，对比Docker swarm集群，master相当于docker swarm集群中的manager，而minion则相当于docker swarm集群中的worker。

在master节点上运行的k8s核心组件包括：

# ls /opt/bin|grep kube
kube-apiserver
kube-controller-manager
kubelet
kube-proxy
kube-scheduler

在minion节点上，k8s核心组件较少，包括：

# ls /opt/bin|grep kube
kubelet
kube-proxy

k8s的安装模型可以概述为：在安装机上将k8s的各个组件分别部署到不同角色的节点上去(通过ssh远程登录到各节点)，并启动起来。用下面这个简易图表达起来可能更加形象：

安装机(放置k8s的安装程序和安装脚本） ----- install k8s core components to(via ssh) ---->  master and minion nodes

在安装之前，这里再明确一下我所用的环境信息：

阿里云ECS: Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-70-generic x86_64)

root@iZ25cn4xxnvZ:~# docker version
Client:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:00:50 2016
OS/Arch: linux/amd64

Server:
Version: 1.12.2
API version: 1.24
Go version: go1.6.3
Git commit: bb80604
Built: Tue Oct 11 17:00:50 2016
OS/Arch: linux/amd64

二、先决条件

根据浙大团队的那篇在Ubuntu上安装k8s的 文章，在真正安装k8s组件之前，需要先满足一些先决条件：

1、安装Docker

关于 Docker的文档，不得不说，写的还是不错的。Docker到目前为止已经发展了许多年了，其在Ubuntu上的安装已经逐渐成熟了。在其 官方文档中有针对ubuntu 12.04、14.04和16.04的详细安装说明。如果你的Ubuntu服务器上docker版本较低，还可以用国内Daocloud提供的 一键安装服务来安装最新版的Docker。

2、安装bridge-utils

安装网桥管理工具：

[sudo] apt-get install bridge-utils

安装后，可以测试一下安装是否ok：

root@iZ25cn4xxnvZ:~# brctl show
bridge name    bridge id        STP enabled    interfaces
docker0        8000.0242988b938c    no        veth901efcb
docker_gwbridge        8000.0242bffb02d5    no        veth21546ed
                            veth984b294

3、确保master node可以连接互联网并下载必要的文件

这里要提到的是为master node配置上”加速器”。同时如果master node还承担逻辑上的minion node角色，还需要为节点上Docker配置上加速器（如果加速器是通过代理配置的），minion node上亦是如此，比如：

/etc/default/docker

export http_proxy=http://duotai:xxxxx@sheraton.h.xduotai.com:24448
export https_proxy=$http_proxy

4、在安装机上配置自动 免密ssh登录各个master node 和minion node

我在阿里云上开了两个ECS（暂成为node1 – 10.47.136.60和node2 – 10.46.181.146），我的k8s集群就由这两个物理node承载，但在逻辑上node1和node2承担着多种角色，逻辑上这是一个由一个master node和两个minion node组成的k8s集群：

安装机：node1
master node：node1
minion node: node1和node2

因此为了满足安装机到各个k8s node免密ssh登录的先决条件，我需要实现从安装机(node1)到master node(node1)和minion node(node1和node2)的免费ssh登录设置。

在安装机node上执行：

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
... ...

安装机免密登录逻辑意义上的master node(实际上就是登录自己，即node1）：

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

安装机免费登录minion node(node2)：

将公钥复制到server：
#scp ~/.ssh/id_rsa.pub root@10.46.181.146:/root/id_rsa.pub
The authenticity of host '10.46.181.146 (10.46.181.146)' can't be established.
ECDSA key fingerprint is b7:31:8d:33:f5:6e:ef:a4:a1:cc:72:5f:cf:68:c6:3d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.46.181.146' (ECDSA) to the list of known hosts.
root@10.46.181.146's password:
id_rsa.pub

在minion node，即node2上，导入安装机的公钥并修改访问权限：

cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
root@iZ25mjza4msZ:~# chmod 700 ~/.ssh
root@iZ25mjza4msZ:~#     chmod 600 ~/.ssh/authorized_keys

配置完成，你可以在安装机上测试一下到自身(node1)和到node2的免密登录，以免密登录node2为例：

root@iZ25cn4xxnvZ:~/.ssh# ssh 10.46.181.146
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.19.0-70-generic x86_64)

 * Documentation:  https://help.ubuntu.com/
New release '16.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Welcome to aliyun Elastic Compute Service!

Last login: Thu Oct 13 12:55:21 2016 from 218.25.32.210

5、下载pause-amd64镜像

k8s集群启动后，启动容器时会去下载google的gcr.io/google_containers下的一个pause-amd64镜像，为了避免那时出错时不便于查找，这些先下手为强，先通过“加速器”将该镜像下载到各个k8s node上：

修改/etc/default/docker，添加带有加速器的http_proxy/https_proxy，并增加–insecure-registry gcr.io

# If you need Docker to use an HTTP proxy, it can also be specified here.
export http_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448
export https_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448

# This is also a handy place to tweak where Docker's temporary files go.
#export TMPDIR="/mnt/bigdrive/docker-tmp"
DOCKER_OPTS="$DOCKER_OPTS -H unix:///var/run/docker.sock -H tcp://0.0.0.0:2375 --insecure-registry gcr.io"

重启docker daemon服务。下载pause-amd64 image：

root@iZ25cn4xxnvZ:~# docker search gcr.io/google_containers/pause-amd64
NAME                            DESCRIPTION   STARS     OFFICIAL   AUTOMATED
google_containers/pause-amd64                 0
root@iZ25cn4xxnvZ:~# docker pull gcr.io/google_containers/pause-amd64
Using default tag: latest
Pulling repository gcr.io/google_containers/pause-amd64
Tag latest not found in repository gcr.io/google_containers/pause-amd64

latest标签居然都没有，尝试下载3.0标签的pause-amd64：

root@iZ25cn4xxnvZ:~# docker pull gcr.io/google_containers/pause-amd64:3.0
3.0: Pulling from google_containers/pause-amd64
a3ed95caeb02: Pull complete
f11233434377: Pull complete
Digest: sha256:163ac025575b775d1c0f9bf0bdd0f086883171eb475b5068e7defa4ca9e76516
Status: Downloaded newer image for gcr.io/google_containers/pause-amd64:3.0

三、设置工作目录，进行安装前的各种配置

到目前为止，所有node上，包括安装机node上还是“一无所有”的。接下来，我们开始在安装机node上做文章。

俗话说：“巧妇不为无米炊”。安装机想在各个node上安装k8s组件，安装机本身就要有”米”才行，这个米就是k8s源码包或release包中的安装脚本。

在官方文档中，这个获取“米”的步骤为clone k8s的源码库。由于之前就下载了 k8s 1.3.7的release包，这里我就直接使用release包中的”米”。

解压kubernetes.tar.gz后，在当前目录下将看到kubernetes目录：

root@iZ25cn4xxnvZ:~/k8stest/1.3.7/kubernetes# ls -F
cluster/  docs/  examples/  federation/  LICENSES  platforms/  README.md  server/  third_party/  Vagrantfile  version

这个kubernetes目录就是我们安装k8s的 工作目录。由于我们在ubuntu上安装k8s，因此我们实际上要使用的脚本都在工作目录下的cluster/ubuntu下面，后续有详细说明。

在安装机上，我们最终是要执行这样一句脚本的：

KUBERNETES_PROVIDER=ubuntu ./cluster/kube-up.sh

在provider=ubuntu的情况下，./cluster/kube-up.sh最终会调用到./cluster/ubuntu/util.sh中的kube-up shell函数，kube-up函数则会调用./cluster/ubuntu/download-release.sh下载k8s安装所使用到的所有包，包括k8s的安装包(kubernetes.tar.gz)、etcd和flannel等。由于之前我们已经下载完k8s的1.3.7版本release包了，这里我们就需要对down-release.sh做一些修改，防止重新下载，导致安装时间过长。

./cluster/ubuntu/download-release.sh

    # KUBE_VERSION=$(get_latest_version_number | sed 's/^v//')
    #curl -L https://github.com/kubernetes/kubernetes/releases/download/v${KUBE_VERSION}/kubernetes.tar.gz -o kubernetes.tar.gz

这种情况下，你还需要把已经下载的kubernetes.tar.gz文件copy一份，放到./cluster/ubuntu下面。

如果你的网络访问国外主机足够快，你还有足够耐心，那么你大可忽略上面脚本修改的步骤。

在真正执行./cluster/kube-up.sh之前，安装机还需要知道：

1、k8s物理集群都有哪些node组成，node的角色都是什么？
2、k8s的各个依赖程序，比如etcd的版本是什么？

我们需要通过配置./cluster/ubuntu/config-default.sh让./cluster/kube-up.sh获取这些信息。

./cluster/ubuntu/config-default.sh

# node信息，本集群由两个物理node组成，其中第一个node既是master，也是minion
export nodes=${nodes:-"root@10.47.136.60  root@10.46.181.146"}
roles=${roles:-"ai i"}

# minion node个数
export NUM_NODES=${NUM_NODES:-2}

# 为安装脚本配置网络代理，这里主要是为了使用加速器，方便或加速下载一些包
PROXY_SETTING=${PROXY_SETTING:-"http_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448 https_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448"}

通过环境变量设置k8s要下载的依赖程序的版本：

export KUBE_VERSION=1.3.7
export FLANNEL_VERSION=0.5.5
export ETCD_VERSION=3.0.12

如果不设置环境变量，./cluster/ubuntu/download-release.sh中默认的版本号将是：

k8s： 最新版本
etcd：2.3.1
flannel : 0.5.5

四、执行安装

在安装机上，进入./cluster目录，执行如下安装命令：

KUBERNETES_PROVIDER=ubuntu ./kube-up.sh

执行输出如下：

root@iZ25cn4xxnvZ:~/k8stest/1.3.7/kubernetes/cluster# KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
... Starting cluster using provider: ubuntu
... calling verify-prereqs
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
... calling kube-up
~/k8stest/1.3.7/kubernetes/cluster/ubuntu ~/k8stest/1.3.7/kubernetes/cluster

Prepare flannel 0.5.5 release ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   608    0   608    0     0    410      0 --:--:--  0:00:01 --:--:--   409
100 3408k  100 3408k    0     0   284k      0  0:00:11  0:00:11 --:--:--  389k

Prepare etcd 3.0.12 release ...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   607    0   607    0     0    388      0 --:--:--  0:00:01 --:--:--   388
  3  9.8M    3  322k    0     0  84238      0  0:02:02  0:00:03  0:01:59  173k
100  9.8M  100  9.8M    0     0   327k      0  0:00:30  0:00:30 --:--:--  344k

Prepare kubernetes 1.3.7 release ...

~/k8stest/1.3.7/kubernetes/cluster/ubuntu/kubernetes/server ~/k8stest/1.3.7/kubernetes/cluster/ubuntu ~/k8stest/1.3.7/kubernetes/cluster
~/k8stest/1.3.7/kubernetes/cluster/ubuntu ~/k8stest/1.3.7/kubernetes/cluster

Done! All your binaries locate in kubernetes/cluster/ubuntu/binaries directory
~/k8stest/1.3.7/kubernetes/cluster

Deploying master and node on machine 10.47.136.60
saltbase/salt/generate-cert/make-ca-cert.sh: No such file or directory
easy-rsa.tar.gz                                                                                                                               100%   42KB  42.4KB/s   00:00
config-default.sh                                                                                                                             100% 5610     5.5KB/s   00:00
util.sh                                                                                                                                       100%   29KB  28.6KB/s   00:00
kubelet.conf                                                                                                                                  100%  644     0.6KB/s   00:00
kube-proxy.conf                                                                                                                               100%  684     0.7KB/s   00:00
kubelet                                                                                                                                       100% 2158     2.1KB/s   00:00
kube-proxy                                                                                                                                    100% 2233     2.2KB/s   00:00
etcd.conf                                                                                                                                     100%  709     0.7KB/s   00:00
kube-scheduler.conf                                                                                                                           100%  674     0.7KB/s   00:00
kube-apiserver.conf                                                                                                                           100%  674     0.7KB/s   00:00
kube-controller-manager.conf                                                                                                                  100%  744     0.7KB/s   00:00
kube-scheduler                                                                                                                                100% 2360     2.3KB/s   00:00
kube-controller-manager                                                                                                                       100% 2672     2.6KB/s   00:00
kube-apiserver                                                                                                                                100% 2358     2.3KB/s   00:00
etcd                                                                                                                                          100% 2073     2.0KB/s   00:00
reconfDocker.sh                                                                                                                               100% 2074     2.0KB/s   00:00
kube-scheduler                                                                                                                                100%   56MB  56.2MB/s   00:01
kube-controller-manager                                                                                                                       100%   95MB  95.4MB/s   00:01
kube-apiserver                                                                                                                                100%  105MB 104.9MB/s   00:00
etcdctl                                                                                                                                       100%   18MB  17.6MB/s   00:00
flanneld                                                                                                                                      100%   16MB  15.8MB/s   00:01
etcd                                                              100% 2074     2.0KB/s   00:00
kube-scheduler                                                                                              100%   56MB  56.2MB/s   0         100%   56MB  56.2MB/s   00:01
kube-controller-manager                                                                                     100%   95MB  95.4MB/s             100%   95MB  95.4MB/s   00:01
kube-apiserver                                                                                             100%  105MB 104.9MB/s              100%  105MB 104.9MB/s   00:00
etcdctl                                                                                                    100%   18MB  17.6MB/s us           100%   18MB  17.6MB/s   00:00
flanneld                 10                                                                                100%   16MB  15.8MB/sge            100%   16MB  15.8MB/s   00:01

... ...

结果中并没有出现代表着安装成功的如下log字样：

Cluster validation succeeded

查看上面安装日志输出，发现在向10.47.136.60 master节点部署组件时，出现如下错误日志：

saltbase/salt/generate-cert/make-ca-cert.sh: No such file or directory

查看一下./cluster下的确没有saltbase目录，这个问题在网上找到了答案，解决方法如下：

k8s安装包目录下，在./server/kubernetes下已经有salt包：kubernetes-salt.tar.gz，解压后，将saltbase整个目录cp到.cluster/下即可。

再次执行：KUBERNETES_PROVIDER=ubuntu ./kube-up.sh，可以看到如下执行输出：

... ...

Deploying master and node on machine 10.47.136.60
make-ca-cert.sh                                                                                                                               100% 4028     3.9KB/s   00:00
easy-rsa.tar.gz                                                                                                                               100%   42KB  42.4KB/s   00:00
config-default.sh                                                                                                                             100% 5632     5.5KB/s   00:00
util.sh                                                                                                                                       100%   29KB  28.6KB/s   00:00
kubelet.conf                                                                                                                                  100%  644     0.6KB/s   00:00
kube-proxy.conf                                                                                                                               100%  684     0.7KB/s   00:00
kubelet                                                                                                                                       100% 2158     2.1KB/s   00:00
kube-proxy                                                                                                                                    100% 2233     2.2KB/s   00:00
etcd.conf                                                                                                                                     100%  709     0.7KB/s   00:00
kube-scheduler.conf                                                                                                                           100%  674     0.7KB/s   00:00
kube-apiserver.conf                                                                                                                           100%  674     0.7KB/s   00:00
kube-controller-manager.conf                                                                                                                  100%  744     0.7KB/s   00:00
kube-scheduler                                                                                                                                100% 2360     2.3KB/s   00:00
kube-controller-manager                                                                                                                       100% 2672     2.6KB/s   00:00
kube-apiserver                                                                                                                                100% 2358     2.3KB/s   00:00
etcd                                                                                                                                          100% 2073     2.0KB/s   00:00
reconfDocker.sh                                                                                                                               100% 2074     2.0KB/s   00:00
kube-scheduler                                                                                                                                100%   56MB  56.2MB/s   00:01
kube-controller-manager                                                                                                                       100%   95MB  95.4MB/s   00:00
kube-apiserver                                                                                                                                100%  105MB 104.9MB/s   00:01
etcdctl                                                                                                                                       100%   18MB  17.6MB/s   00:00
flanneld                                                                                                                                      100%   16MB  15.8MB/s   00:00
etcd                                                                                                                                          100%   19MB  19.3MB/s   00:00
flanneld                                                                                                                                      100%   16MB  15.8MB/s   00:00
kubelet                                                                                                                                       100%  103MB 103.1MB/s   00:01
kube-proxy                                                                                                                                    100%   48MB  48.4MB/s   00:00
flanneld.conf                                                                                                                                 100%  577     0.6KB/s   00:00
flanneld                                                                                                                                      100% 2121     2.1KB/s   00:00
flanneld.conf                                                                                                                                 100%  568     0.6KB/s   00:00
flanneld                                                                                                                                      100% 2131     2.1KB/s   00:00
etcd start/running, process 7997
Error:  dial tcp 127.0.0.1:2379: getsockopt: connection refused
{"Network":"172.16.0.0/16", "Backend": {"Type": "vxlan"}}
{"Network":"172.16.0.0/16", "Backend": {"Type": "vxlan"}}
docker stop/waiting
docker start/running, process 8220
Connection to 10.47.136.60 closed.

Deploying node on machine 10.46.181.146
config-default.sh                                                                                                                             100% 5632     5.5KB/s   00:00
util.sh                                                                                                                                       100%   29KB  28.6KB/s   00:00
reconfDocker.sh                                                                                                                               100% 2074     2.0KB/s   00:00
kubelet.conf                                                                                                                                  100%  644     0.6KB/s   00:00
kube-proxy.conf                                                                                                                               100%  684     0.7KB/s   00:00
kubelet                                                                                                                                       100% 2158     2.1KB/s   00:00
kube-proxy                                                                                                                                    100% 2233     2.2KB/s   00:00
flanneld                                                                                                                                      100%   16MB  15.8MB/s   00:00
kubelet                                                                                                                                       100%  103MB 103.1MB/s   00:01
kube-proxy                                                                                                                                    100%   48MB  48.4MB/s   00:00
flanneld.conf                                                                                                                                 100%  577     0.6KB/s   00:00
flanneld                                                                                                                                      100% 2121     2.1KB/s   00:00
flanneld start/running, process 2365
docker stop/waiting
docker start/running, process 2574
Connection to 10.46.181.146 closed.
Validating master
Validating root@10.47.136.60
Validating root@10.46.181.146
Using master 10.47.136.60
cluster "ubuntu" set.
user "ubuntu" set.
context "ubuntu" set.
switched to context "ubuntu".
Wrote config for ubuntu to /root/.kube/config
... calling validate-cluster

Error from server: an error on the server has prevented the request from succeeding
(kubectl failed, will retry 2 times)

Error from server: an error on the server has prevented the request from succeeding
(kubectl failed, will retry 1 times)

Error from server: an error on the server has prevented the request from succeeding
('kubectl get nodes' failed, giving up)

安装并未成功，至少calling validate-cluster后的validation过程并未成功。

但是和第一次的失败有所不同的是，在master node和minion node上，我们都可以看到已经安装并启动了的k8s核心组件：

master node：

root@iZ25cn4xxnvZ:~/k8stest/1.3.7/kubernetes/cluster# ps -ef|grep kube
root      8006     1  0 16:39 ?        00:00:00 /opt/bin/kube-scheduler --logtostderr=true --master=127.0.0.1:8080
root      8008     1  0 16:39 ?        00:00:01 /opt/bin/kube-apiserver --insecure-bind-address=0.0.0.0 --insecure-port=8080 --etcd-servers=http://127.0.0.1:4001 --logtostderr=true --service-cluster-ip-range=192.168.3.0/24 --admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,SecurityContextDeny,ResourceQuota --service-node-port-range=30000-32767 --advertise-address=10.47.136.60 --client-ca-file=/srv/kubernetes/ca.crt --tls-cert-file=/srv/kubernetes/server.cert --tls-private-key-file=/srv/kubernetes/server.key
root      8009     1  0 16:39 ?        00:00:02 /opt/bin/kube-controller-manager --master=127.0.0.1:8080 --root-ca-file=/srv/kubernetes/ca.crt --service-account-private-key-file=/srv/kubernetes/server.key --logtostderr=true
root      8021     1  0 16:39 ?        00:00:04 /opt/bin/kubelet --hostname-override=10.47.136.60 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config=
root      8023     1  0 16:39 ?        00:00:00 /opt/bin/kube-proxy --hostname-override=10.47.136.60 --master=http://10.47.136.60:8080 --logtostderr=true

minion node：

root@iZ25mjza4msZ:~# ps -ef|grep kube
root      2370     1  0 16:39 ?        00:00:04 /opt/bin/kubelet --hostname-override=10.46.181.146 --api-servers=http://10.47.136.60:8080 --logtostderr=true --cluster-dns=192.168.3.10 --cluster-domain=cluster.local --config=
root      2371     1  0 16:39 ?        00:00:00 /opt/bin/kube-proxy --hostname-override=10.46.181.146 --master=http://10.47.136.60:8080 --logtostderr=true

那为什么安装节点上的安装脚本在验证安装是否成功时一直阻塞、最终超时失败呢？我在安装节点，同时也是master node上执行了一下kubectl get node命令：

root@iZ25cn4xxnvZ:~/k8stest/1.3.7/kubernetes/cluster# kubectl get nodes

Error from server: an error on the server ("<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\" \"http://www.w3.org/TR/html4/strict.dtd\">\n<html><head>\n<meta type=\"copyright\" content=\"Copyright (C) 1996-2015 The Squid Software Foundation and contributors\">\n<meta http-equiv=\"Content-Type\" CONTENT=\"text/html; charset=utf-8\">\n<title>ERROR: The requested URL could not be retrieved</title>\n<style type=\"text/css\"><!-- \n /*\n * Copyright (C) 1996-2015 The Squid Software Foundation and contributors\n *\n * Squid software is distributed under GPLv2+ license and includes\n * contributions from numerous individuals and organizations.\n * Please see the COPYING and CONTRIBUTORS files for details.\n */\n\n/*\n Stylesheet for Squid Error pages\n Adapted from design by Free CSS Templates\n http://www.freecsstemplates.org\n Released for free under a Creative Commons Attribution 2.5 License\n*/\n\n/* Page basics */\n* {\n\tfont-family: verdana, sans-serif;\n}\n\nhtml body {\n\tmargin: 0;\n\tpadding: 0;\n\tbackground: #efefef;\n\tfont-size: 12px;\n\tcolor: #1e1e1e;\n}\n\n/* Page displayed title area */\n#titles {\n\tmargin-left: 15px;\n\tpadding: 10px;\n\tpadding-left: 100px;\n\tbackground: url('/squid-internal-static/icons/SN.png') no-repeat left;\n}\n\n/* initial title */\n#titles h1 {\n\tcolor: #000000;\n}\n#titles h2 {\n\tcolor: #000000;\n}\n\n/* special event: FTP success page titles */\n#titles ftpsuccess {\n\tbackground-color:#00ff00;\n\twidth:100%;\n}\n\n/* Page displayed body content area */\n#content {\n\tpadding: 10px;\n\tbackground: #ffffff;\n}\n\n/* General text */\np {\n}\n\n/* error brief description */\n#error p {\n}\n\n/* some data which may have caused the problem */\n#data {\n}\n\n/* the error message received from the system or other software */\n#sysmsg {\n}\n\npre {\n    font-family:sans-serif;\n}\n\n/* special event: FTP / Gopher directory listing */\n#dirmsg {\n    font-family: courier;\n    color: black;\n    font-size: 10pt;\n}\n#dirlisting {\n    margin-left: 2%;\n    margin-right: 2%;\n}\n#dirlisting tr.entry td.icon,td.filename,td.size,td.date {\n    border-bottom: groove;\n}\n#dirlisting td.size {\n    width: 50px;\n    text-align: right;\n    padding-right: 5px;\n}\n\n/* horizontal lines */\nhr {\n\tmargin: 0;\n}\n\n/* page displayed footer area */\n#footer {\n\tfont-size: 9px;\n\tpadding-left: 10px;\n}\n\n\nbody\n:lang(fa) { direction: rtl; font-size: 100%; font-family: Tahoma, Roya, sans-serif; float: right; }\n:lang(he) { direction: rtl; }\n --></style>\n</head><body id=ERR_CONNECT_FAIL>\n<div id=\"titles\">\n<h1>ERROR</h1>\n<h2>The requested URL could not be retrieved</h2>\n</div>\n<hr>\n\n<div id=\"content\">\n<p>The following error was encountered while trying to retrieve the URL: <a href=\"http://10.47.136.60:8080/api\">http://10.47.136.60:8080/api</a></p>\n\n<blockquote id=\"error\">\n<p><b>Connection to 10.47.136.60 failed.</b></p>\n</blockquote>\n\n<p id=\"sysmsg\">The system returned: <i>(110) Connection timed out</i></p>\n\n<p>The remote host or network may be down. Please try the request again.</p>\n\n<p>Your cache administrator is <a href=\"mailto:webmaster?subject=CacheErrorInfo%20-%20ERR_CONNECT_FAIL&amp;body=CacheHost%3A%20192-241-236-182%0D%0AErrPage%3A%20ERR_CONNECT_FAIL%0D%0AErr%3A%20(110)%20Connection%20timed%20out%0D%0ATimeStamp%3A%20Thu,%2013%20Oct%202016%2008%3A49%3A35%20GMT%0D%0A%0D%0AClientIP%3A%20127.0.0.1%0D%0AServerIP%3A%2010.47.136.60%0D%0A%0D%0AHTTP%20Request%3A%0D%0AGET%20%2Fapi%20HTTP%2F1.1%0AUser-Agent%3A%20kubectl%2Fv1.4.0%20(linux%2Famd64)%20kubernetes%2F4b28af1%0D%0AAccept%3A%20application%2Fjson,%20*%2F*%0D%0AAccept-Encoding%3A%20gzip%0D%0AHost%3A%2010.47.136.60%3A8080%0D%0A%0D%0A%0D%0A\">webmaster</a>.</p>\n\n<br>\n</div>\n\n<hr>\n<div id=\"footer\">\n<p>Generated Thu, 13 Oct 2016 08:49:35 GMT by 192-241-236-182 (squid/3.5.12)</p>\n<!-- ERR_CONNECT_FAIL -->\n</div>\n</body></html>") has prevented the request from succeeding

可以看到kubectl得到一坨信息，这是一个html页面内容的数据，仔细分析body内容，我们可以看到：

<body id=ERR_CONNECT_FAIL>\n<div id=\"titles\">\n<h1>ERROR</h1>\n<h2>The requested URL could not be retrieved</h2>\n</div>\n<hr>\n\n<div id=\"content\">\n<p>The following error was encountered while trying to retrieve the URL: <a href=\"http://10.47.136.60:8080/api\">http://10.47.136.60:8080/api</a></p>\n\n<blockquote id=\"error\">\n<p><b>Connection to 10.47.136.60 failed.</b></p>\n</blockquote>\n\n<p id=\"sysmsg\">The system returned: <i>(110) Connection timed out</i></p>\n\n<p>The remote host or network may be down. Please try the request again.</p>

kubectl在访问http://10.47.136.60:8080/api这个url时出现了timed out错误。在master node上直接执行curl http://10.47.136.60:8080/api也是这个错误。猜想是否是我.bashrc中的http_proxy在作祟。于是在.bashrc中增加no_proxy:

export no_proxy='10.47.136.60,10.46.181.146,localhost,127.0.0.1'

生效后，再在master node上执行curl：

# curl http://10.47.136.60:8080/api
{"kind": "APIVersions","versions": ["v1"
  ],"serverAddressByClientCIDRs": [
    {"clientCIDR": "0.0.0.0/0","serverAddress": "10.47.136.60:6443"
    }
  ]
}

看来问题原因就是安装程序的PROXY_SETTING中没有加入no_proxy的设置的缘故，于是修改config-default.sh中的代理设置：

PROXY_SETTING=${PROXY_SETTING:-"http_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448 https_proxy=http://duotai:xxxx@sheraton.h.xduotai.com:24448 no_proxy=10.47.136.60,10.46.181.146,localhost,127.0.0.1"}

然后重新deploy：

root@iZ25cn4xxnvZ:~/k8stest/1.3.7/kubernetes/cluster# KUBERNETES_PROVIDER=ubuntu ./kube-up.sh
... Starting cluster using provider: ubuntu
... calling verify-prereqs
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
... calling kube-up
~/k8stest/1.3.7/kubernetes/cluster/ubuntu ~/k8stest/1.3.7/kubernetes/cluster
Prepare flannel 0.5.5 release ...
Prepare etcd 3.0.12 release ...
Prepare kubernetes 1.3.7 release ...
Done! All your binaries locate in kubernetes/cluster/ubuntu/binaries directory
~/k8stest/1.3.7/kubernetes/cluster

Deploying master and node on machine 10.47.136.60
make-ca-cert.sh                                                                                                                               100% 4028     3.9KB/s   00:00
easy-rsa.tar.gz                                                                                                                               100%   42KB  42.4KB/s   00:00
config-default.sh                                                                                                                             100% 5678     5.5KB/s   00:00
... ...
cp: cannot create regular file ‘/opt/bin/etcd’: Text file busy
cp: cannot create regular file ‘/opt/bin/flanneld’: Text file busy
cp: cannot create regular file ‘/opt/bin/kube-apiserver’: Text file busy
cp: cannot create regular file ‘/opt/bin/kube-controller-manager’: Text file busy
cp: cannot create regular file ‘/opt/bin/kube-scheduler’: Text file busy
Connection to 10.47.136.60 closed.
Deploying master and node on machine 10.47.136.60 failed

重新部署时，由于之前k8s cluster在各个node的组件已经启动，因此failed。我们需要通过

KUBERNETES_PROVIDER=ubuntu kube-down.sh

将k8s集群停止后再尝试up，或者如果不用这个kube-down.sh脚本，也可以在各个节点上手动shutdown各个k8s组件(master上有五个核心组件，minion node上有两个核心组件，另外别忘了停止etcd和flanneld服务)，以kube-controller-manager为例：

service kube-controller-manager stop

即可。

再次执行kube-up.sh：

... ...
.. calling validate-cluster
Waiting for 2 ready nodes. 1 ready nodes, 2 registered. Retrying.
Found 2 node(s).
NAME            STATUS    AGE
10.46.181.146   Ready     4h
10.47.136.60    Ready     4h
Validate output:
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health": "true"}
Cluster validation succeeded
Done, listing cluster services:

Kubernetes master is running at http://10.47.136.60:8080

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

通过字样：”Cluster validation succeeded”可以证明我们成功安装了k8s集群。

执行kubectl get node可以看到当前集群的节点组成情况：

# kubectl get node
NAME            STATUS    AGE
10.46.181.146   Ready     4h
10.47.136.60    Ready     4h

通过执行kubectl cluster-info dump 可以看到k8s集群更为详尽的信息。

五、测试k8s的service特性

之所以采用k8s，初衷就是因为Docker 1.12在阿里云搭建的swarm集群的VIP和Routing mesh机制不好用。因此，在k8s集群部署成功后，我们需要测试一下这两种机制在k8s上是否能够获得支持。

k8s中一些关于集群的抽象概念，比如node、deployment、pod、service等，这里就不赘述了，需要的话可以参考 这里的Concept guide。

1、集群内负载均衡

在k8s集群中，有一个等同于docker swarm vip的概念，成为cluster ip，k8s回为每个service分配一个cluster ip，这个cluster ip在service生命周期中不会改变，并且访问cluster ip的请求会被自动负载均衡到service里的后端container中。

我们来启动一个replicas= 2的nginx service，我们需要先从一个描述文件来部署一个deployment：

//run-my-nginx.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx:1.10.1
        ports:
        - containerPort: 80

启动deployment:

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl create -f ./run-my-nginx.yaml
deployment "my-nginx" created

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl get deployment
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
my-nginx   2         2         2            2           9s

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl get pods -l run=my-nginx -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
my-nginx-2395715568-2t6xe   1/1       Running   0          50s       172.16.57.3   10.46.181.146
my-nginx-2395715568-gpljv   1/1       Running   0          50s       172.16.99.2   10.47.136.60

可以看到my-nginx deployment已经成功启动，并且被调度在两个minion node上。

接下来，我们将deployment转化为service:

# kubectl expose deployment/my-nginx
service "my-nginx" exposed

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl get svc my-nginx
NAME       CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
my-nginx   192.168.3.239   <none>        80/TCP    15s

# kubectl describe svc my-nginx
Name:            my-nginx
Namespace:        default
Labels:            run=my-nginx
Selector:        run=my-nginx
Type:            ClusterIP
IP:            192.168.3.239
Port:            <unset>    80/TCP
Endpoints:        172.16.57.3:80,172.16.99.2:80
Session Affinity:    None

我们看到通过expose命令，可以将deployment转化为service，转化后，my-nginx service被分配了一个cluster-ip：192.168.3.239。

我们启动一个client container用于测试内部负载均衡：

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl run myclient --image=registry.cn-hangzhou.aliyuncs.com/mioss/test --replicas=1 --command -- tail -f /var/log/bootstrap.log
deployment "myclient" created

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl get pods
NAME                        READY     STATUS    RESTARTS   AGE
my-nginx-2395715568-2t6xe   1/1       Running   0          24m
my-nginx-2395715568-gpljv   1/1       Running   0          24m
myclient-1460251692-g7rnl   1/1       Running   0          21s

通过docker exec -it containerid /bin/bash进入myclient容器内，通过curl向上面的cluster-ip发起http请求：

root@myclient-1460251692-g7rnl:/# curl -v 192.168.3.239:80

同时在两个minion节点上，通过docker logs -f查看my-nginx service下面的两个nginx container实例日志，可以看到两个container轮询收到http request:

root@iZ25cn4xxnvZ:~/k8stest/demo# docker logs -f  ccc2f9bb814a
172.16.57.0 - - [17/Oct/2016:06:35:57 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.0 - - [17/Oct/2016:06:36:13 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.0 - - [17/Oct/2016:06:37:06 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.0 - - [17/Oct/2016:06:37:45 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.0 - - [17/Oct/2016:06:37:46 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.0 - - [17/Oct/2016:06:37:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

root@iZ25mjza4msZ:~# docker logs -f 0e533ec2dc71
172.16.57.4 - - [17/Oct/2016:06:33:14 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.4 - - [17/Oct/2016:06:33:18 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.4 - - [17/Oct/2016:06:34:06 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.4 - - [17/Oct/2016:06:34:09 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.4 - - [17/Oct/2016:06:35:45 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.4 - - [17/Oct/2016:06:36:59 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

cluster-ip机制有效。

2、nodeport机制

k8s通过nodeport机制实现类似docker的routing mesh，但底层机制和原理是不同的。

k8s的nodePort的原理是在集群中的每个node上开了一个端口，将访问该端口的流量导入到该node上的kube-proxy，然后再由kube-proxy进一步讲流量转发给该对应该nodeport的service的alive的pod上。

我们先来删除掉前面启动的my-nginx service，再重新创建支持nodeport的新my-nginx service。在k8s delete service有点讲究，我们删除service的目的不仅要删除service“索引”，还要stop并删除该service对应的Pod中的所有docker container。但在k8s中，直接删除service或delete pods都无法让对应的container stop并deleted，而是要通过delete service and delete deployment两步才能彻底删除service。

root@iZ25cn4xxnvZ:~# kubectl delete svc my-nginx
service "my-nginx" deleted

root@iZ25cn4xxnvZ:~# kubectl get service my-nginx
Error from server: services "my-nginx" not found

//容器依然在运行
root@iZ25cn4xxnvZ:~# kubectl get deployment my-nginx
NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
my-nginx   2         2         2            2           20h

root@iZ25cn4xxnvZ:~# kubectl delete deployment my-nginx
deployment "my-nginx" deleted

再执行docker ps，看看对应docker container应该已经被删除。

重新创建暴露nodeport的my-nginx服务，我们先来创建一个新的service文件：

//my-nginx-svc.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30062
    protocol: TCP
  selector:
    run: my-nginx

创建服务：

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl create -f ./my-nginx-svc.yaml
deployment "my-nginx" created

查看服务信息：

root@iZ25cn4xxnvZ:~/k8stest/demo# kubectl describe service my-nginx
Name:            my-nginx
Namespace:        default
Labels:            run=my-nginx
Selector:        run=my-nginx
Type:            NodePort
IP:            192.168.3.179
Port:            <unset>    80/TCP
NodePort:        <unset>    30062/TCP
Endpoints:        172.16.57.3:80,172.16.99.2:80
Session Affinity:    None

可以看到与上一次的service信息相比，这里多出一个属性:NodePort 30062/TCP，这个就是整个服务暴露到集群外面的端口。

接下来我们通过这两个node的公网地址访问一下这个暴露的nodeport，看看service中的两个ngnix container是否能收到request：

通过公网ip curl 30062端口:

curl -v x.x.x.x:30062
curl -v  y.y.y.y:30062

同样，我们用docker logs -f来监控两个nginx container的日志输出，可以看到：

nginx1:

172.16.57.4 - - [17/Oct/2016:08:19:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
172.16.57.1 - - [17/Oct/2016:08:21:55 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.1 - - [17/Oct/2016:08:21:56 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.1 - - [17/Oct/2016:08:21:59 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.1 - - [17/Oct/2016:08:22:07 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.1 - - [17/Oct/2016:08:22:09 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"

nginx2：

172.16.57.0 - - [17/Oct/2016:08:22:05 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.0 - - [17/Oct/2016:08:22:06 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.0 - - [17/Oct/2016:08:22:08 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.0 - - [17/Oct/2016:08:22:09 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"

两个container轮询地收到外部转来的http request。

现在我们将my-nginx服务的scale由2缩减为1：

root@iZ25cn4xxnvZ:~# kubectl scale --replicas=1 deployment/my-nginx
deployment "my-nginx" scaled

再次测试nodeport机制：

curl -v x.x.x.x:30062
curl -v  y.y.y.y:30062

scale后，只有master上的my-nginx存活。由于nodeport机制，没有my-nginx上的node收到请求后，将请求转给kube-proxy，通过内部clusterip机制，发给有my-nginx的container。

master上的nginx container：

172.16.99.1 - - [18/Oct/2016:00:55:04 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"
172.16.57.0 - - [18/Oct/2016:00:55:10 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.30.0" "-"

nodeport机制测试ok。通过netstat我们可以看到30062端口是node上的kube-proxy监听的端口，因此即便该node上没有nginx服务container运行，kube-proxy也会转发request。

root@iZ25cn4xxnvZ:~# netstat -tnlp|grep 30062
tcp6       0      0 :::30062                :::*                    LISTEN      22076/kube-proxy

六、尾声

到这里，k8s集群已经是可用的了。但要用好背后拥有15年容器经验沉淀的k8s，还有很长的路要走，比如安装Addon（DNS plugin等）、比如安装Dashboard等。这些在这里暂不提了，文章已经很长了。后续可能会有单独文章说明。

© 2016, bigwhite. 版权所有.

以前不理解什么叫回调，天天听人家说加一个回调方法啥的，心里想我草，什么叫回调方法啊？然后自己就在网上找啊找啊找，找了很多也不是很明白，现在知道了，所谓回调：就是A类中调用B类中的某个方法C，然后B类中反过来调用A类中的方法D，D这个方法就叫回调方法，这样子说你是不是有点晕晕的，其实我刚开始也是这样不理解，看了人家说比较经典的回调方式：

• Class A实现接口CallBack callback—— 背景1
• class A中包含一个class B的引用b —— 背景2
• class B有一个参数为callback的方法f(CallBack callback) —— 背景3
• A的对象a调用B的方法 f(CallBack callback) ——A类调用B类的某个方法 C
• 然后b就可以在f(CallBack callback)方法中调用A的方法 ——B类调用A类的某个方法D

大家都喜欢用打电话的例子，好吧，为了跟上时代，我也用这个例子好了，我这个例子采用异步加回调

有一天小王遇到一个很难的问题，问题是“1 + 1 = ?”，就打电话问小李，小李一下子也不知道，就跟小王说，等我办完手上的事情，就去想想答案，小王也不会傻傻的拿着电话去等小李的答案吧，于是小王就对小李说，我还要去逛街，你知道了答案就打我电话告诉我，于是挂了电话，自己办自己的事情，过了一个小时，小李打了小王的电话，告诉他答案是2

/** 
 * 这是一个回调接口 
 * @author xiaanming 
 * 
 */  
public interface CallBack {  
    /** 
     * 这个是小李知道答案时要调用的函数告诉小王，也就是回调函数 
     * @param result 是答案 
     */  
    public void solve(String result);  
}

/** 
 * 这个是小王 
 * @author xiaanming 
 * 实现了一个回调接口CallBack，相当于----->背景一 
 */  
public class Wang implements CallBack {  
    /** 
     * 小李对象的引用 
     * 相当于----->背景二 
     */  
    private Li li;   

    /** 
     * 小王的构造方法，持有小李的引用 
     * @param li 
     */  
    public Wang(Li li){  
        this.li = li;  
    }  

    /** 
     * 小王通过这个方法去问小李的问题 
     * @param question  就是小王要问的问题,1 + 1 = ? 
     */  
    public void askQuestion(final String question){  
        //这里用一个线程就是异步，  
        new Thread(new Runnable() {  
            @Override  
            public void run() {  
                /** 
                 * 小王调用小李中的方法，在这里注册回调接口 
                 * 这就相当于A类调用B的方法C 
                 */  
                li.executeMessage(Wang.this, question);   
            }  
        }).start();  

        //小网问完问题挂掉电话就去干其他的事情了，诳街去了  
        play();  
    }  

    public void play(){  
        System.out.println("我要逛街去了");  
    }  

    /** 
     * 小李知道答案后调用此方法告诉小王，就是所谓的小王的回调方法 
     */  
    @Override  
    public void solve(String result) {  
        System.out.println("小李告诉小王的答案是--->" + result);  
    }  

}

/** 
 * 这个就是小李啦 
 * @author xiaanming 
 * 
 */  
public class Li {  
    /** 
     * 相当于B类有参数为CallBack callBack的f()---->背景三 
     * @param callBack   
     * @param question  小王问的问题 
     */  
    public void executeMessage(CallBack callBack, String question){  
        System.out.println("小王问的问题--->" + question);  

        //模拟小李办自己的事情需要很长时间  
        for(int i=0; i<10000;i++){  

        }  

        /** 
         * 小李办完自己的事情之后想到了答案是2 
         */  
        String result = "答案是2";  

        /** 
         * 于是就打电话告诉小王，调用小王中的方法 
         * 这就相当于B类反过来调用A的方法D 
         */  
        callBack.solve(result);   

    }  

}

/** 
 * 测试类 
 * @author xiaanming 
 * 
 */  
public class Test {  
    public static void main(String[]args){  
        /** 
         * new 一个小李 
         */  
        Li li = new Li();  

        /** 
         * new 一个小王 
         */  
        Wang wang = new Wang(li);  

        /** 
         * 小王问小李问题 
         */  
        wang.askQuestion("1 + 1 = ?");  
    }  
}

通过上面的那个例子你是不是差不多明白了回调机制呢，上面是一个异步回调，我们看看同步回调吧，onClick（）方法

现在来分析分析下 Android View的点击方法onclick（）;我们知道onclick()是一个回调方法，当用户点击View就执行这个方法，我们用Button来举例好了

//这个是View的一个回调接口  
/** 
 * Interface definition for a callback to be invoked when a view is clicked. 
 */  
public interface OnClickListener {  
    /** 
     * Called when a view has been clicked. 
     * 
     * @param v The view that was clicked. 
     */  
    void onClick(View v);  
}

package com.example.demoactivity;  

import android.app.Activity;  
import android.os.Bundle;  
import android.view.View;  
import android.view.View.OnClickListener;  
import android.widget.Button;  
import android.widget.Toast;  

/** 
 * 这个就相当于Class A 
 * @author xiaanming 
 * 实现了 OnClickListener接口---->背景一 
 */  
public class MainActivity extends Activity implements OnClickListener{  
    /** 
     * Class A 包含Class B的引用----->背景二 
     */  
    private Button button;  

    @Override  
    public void onCreate(Bundle savedInstanceState) {  
        super.onCreate(savedInstanceState);  
        setContentView(R.layout.activity_main);  
        button = (Button)findViewById(R.id.button1);  

        /** 
         * Class A 调用View的方法,而Button extends View----->A类调用B类的某个方法 C 
         */  
        button.setOnClickListener(this);  
    }  

    /** 
     * 用户点击Button时调用的回调函数，你可以做你要做的事 
     * 这里我做的是用Toast提示OnClick 
     */  
    @Override  
    public void onClick(View v) {  
        Toast.makeText(getApplication(), "OnClick", Toast.LENGTH_LONG).show();  
    }  

}

下面是View类的setOnClickListener方法，就相当于B类咯，只把关键代码贴出来

/** 
 * 这个View就相当于B类 
 * @author xiaanming 
 * 
 */  
public class View implements Drawable.Callback, KeyEvent.Callback, AccessibilityEventSource {  
    /** 
     * Listener used to dispatch click events. 
     * This field should be made private, so it is hidden from the SDK. 
     * {@hide} 
     */  
    protected OnClickListener mOnClickListener;  

    /** 
     * setOnClickListener()的参数是OnClickListener接口------>背景三 
     * Register a callback to be invoked when this view is clicked. If this view is not 
     * clickable, it becomes clickable. 
     * 
     * @param l The callback that will run 
     * 
     * @see #setClickable(boolean) 
     */  

    public void setOnClickListener(OnClickListener l) {  
        if (!isClickable()) {  
            setClickable(true);  
        }  
        mOnClickListener = l;  
    }  

    /** 
     * Call this view's OnClickListener, if it is defined. 
     * 
     * @return True there was an assigned OnClickListener that was called, false 
     *         otherwise is returned. 
     */  
    public boolean performClick() {  
        sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_CLICKED);  

        if (mOnClickListener != null) {  
            playSoundEffect(SoundEffectConstants.CLICK);  

            //这个不就是相当于B类调用A类的某个方法D，这个D就是所谓的回调方法咯  
            mOnClickListener.onClick(this);  
            return true;  
        }  

        return false;  
    }  
}

这个例子就是Android典型的回调机制，看完这个你是不是更进一步的理解了回调机制呢？ 线程run()也是一个回调方法，当执行Thread的start（）方法就会回调这个run()方法，还有处理消息都比较经典等等

相关文章

• Java中实现CallBack功能
• 如何增强JAVA的I/O性能
• Java并发的四种风味：Thread、Executor、ForkJoin和Actor
• Netty实现原理浅析
• ConcurrentHashmap 解析
• 泛型方法的反模式
• Java常用排序算法/程序员必须掌握的8大排序算法
• 跟我学Spring3（3.1）:DI的配置使用
• 跟我学Spring3（12.3）：零配置之注解实现Bean定义
• Java Web前端到后台常用框架介绍

一. 衡量指标

用什么来衡量一个系统的负载能力呢？有一个概念叫做每秒请求数（Requests per second），指的是每秒能够成功处理请求的数目。比如说，你可以配置tomcat服务器的maxConnection为无限大，但是受限于服务器系统或者硬件限制，很多请求是不会在一定的时间内得到响应的，这并不作为一个成功的请求，其中成功得到响应的请求数即为每秒请求数，反应出系统的负载能力。

通常的，对于一个系统，增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒”服务器。如果继续增加并发用户数量，每秒请求数量开始下降，而反应时间则会增加。这个并发用户数量开始“压倒”服务器的临界点非常重要，此时的并发用户数量可以认为是当前系统的最大负载能力。

二. 相关因素

一般的，和系统并发访问量相关的几个因素如下：

• 带宽
• 硬件配置
• 系统配置
• 应用服务器配置
• 程序逻辑
• 系统架构

其中，带宽和硬件配置是决定系统负载能力的决定性因素。这些只能依靠扩展和升级提高。我们需要重点关注的是在一定带宽和硬件配置的基础上，怎么使系统的负载能力达到最大。

2.1 带宽

毋庸置疑，带宽是决定系统负载能力的一个至关重要的因素，就好比水管一样，细的水管同一时间通过的水量自然就少（这个比喻解释带宽可能不是特别合适）。一个系统的带宽首先就决定了这个系统的负载能力，其单位为Mbps,表示数据的发送速度。

2.2 硬件配置

系统部署所在的服务器的硬件决定了一个系统的最大负载能力，也是上限。一般说来，以下几个配置起着关键作用：

• cpu频率/核数：cpu频率关系着cpu的运算速度，核数则影响线程调度、资源分配的效率。
• 内存大小以及速度：内存越大，那么可以在内存中运行的数据也就越大，速度自然而然就快；内存的速度从原来的几百hz到现在几千hz，决定了数据读取存储的速度。
• 硬盘速度：传统的硬盘是使用磁头进行寻址的，io速度比较慢，使用了SSD的硬盘，其寻址速度大大较快。

很多系统的架构设计、系统优化，最终都会加上这么一句：使用ssd存储解决了这些问题。

可见，硬件配置是决定一个系统的负载能力的最关键因素。

2.3 系统配置

一般来说，目前后端系统都是部署在Linux主机上的。所以抛开win系列不谈，对于Linux系统来说一般有以下配置关系着系统的负载能力。

• 文件描述符数限制：Linux中所有东西都是文件，一个socket就对应着一个文件描述符，因此系统配置的最大打开文件数以及单个进程能够打开的最大文件数就决定了socket的数目上限。
• 进程/线程数限制: 对于apache使用的prefork等多进程模式，其负载能力由进程数目所限制。对tomcat多线程模式则由线程数所限制。
• tcp内核参数：网络应用的底层自然离不开tcp/ip，Linux内核有一些与此相关的配置也决定了系统的负载能力。

2.3.1 文件描述符数限制

• 系统最大打开文件描述符数：/proc/sys/fs/file-max中保存了这个数目,修改此值

  临时性：
   echo 1000000 > /proc/sys/fs/file-max 
  永久性：
  在/etc/sysctl.conf中设置 fs.file-max = 1000000

• 进程最大打开文件描述符数：这个是配单个进程能够打开的最大文件数目。可以通过ulimit -n查看/修改。如果想要永久修改，则需要修改/etc/security/limits.conf中的nofile。

通过读取/proc/sys/fs/file-nr可以看到当前使用的文件描述符总数。另外，对于文件描述符的配置，需要注意以下几点：

• 所有进程打开的文件描述符数不能超过/proc/sys/fs/file-max
• 单个进程打开的文件描述符数不能超过user limit中nofile的soft limit
• nofile的soft limit不能超过其hard limit
• nofile的hard limit不能超过/proc/sys/fs/nr_open

2.3.2 进程/线程数限制

• 进程数限制：ulimit -u可以查看/修改单个用户能够打开的最大进程数。/etc/security/limits.conf中的noproc则是系统的最大进程数。
• 线程数限制
  • 可以通过/proc/sys/kernel/threads-max查看系统总共可以打开的最大线程数。
  • 单个进程的最大线程数和PTHREAD_THREADS_MAX有关，此限制可以在/usr/include/bits/local_lim.h中查看,但是如果想要修改的话，需要重新编译。
  • 这里需要提到一点的是，Linux内核2.4的线程实现方式为linux threads，是轻量级进程，都会首先创建一个管理线程，线程数目的大小是受PTHREAD_THREADS_MAX影响的。但Linux2.6内核的线程实现方式为NPTL,是一个改进的LWP实现，最大一个区别就是，线程公用进程的pid（tgid），线程数目大小只受制于资源。
  • 线程数的大小还受线程栈大小的制约：使用ulimit -s可以查看/修改线程栈的大小，即每开启一个新的线程需要分配给此线程的一部分内存。减小此值可以增加可以打开的线程数目。

2.3.3 tcp内核参数

在一台服务器CPU和内存资源额定有限的情况下，最大的压榨服务器的性能，是最终的目的。在节省成本的情况下，可以考虑修改Linux的内核TCP/IP参数，来最大的压榨服务器的性能。如果通过修改内核参数也无法解决的负载问题，也只能考虑升级服务器了，这是硬件所限，没有办法的事。

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

使用上面的命令，可以得到当前系统的各个状态的网络连接的数目。如下：

LAST_ACK 13
SYN_RECV 468
ESTABLISHED 90
FIN_WAIT1 259
FIN_WAIT2 40
CLOSING 34
TIME_WAIT 28322

这里，TIME_WAIT的连接数是需要注意的一点。此值过高会占用大量连接，影响系统的负载能力。需要调整参数，以尽快的释放time_wait连接。

一般tcp相关的内核参数在/etc/sysctl.conf文件中。为了能够尽快释放time_wait状态的连接，可以做以下配置：

• net.ipv4.tcp_syncookies = 1 //表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
• net.ipv4.tcp_tw_reuse = 1 //表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
• net.ipv4.tcp_tw_recycle = 1 //表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭；
• net.ipv4.tcp_fin_timeout = 30 //修改系統默认的 TIMEOUT 时间。

这里需要注意的一点就是当打开了tcp_tw_recycle，就会检查时间戳，移动环境下的发来的包的时间戳有些时候是乱跳的，会把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，造成大量丢包。另外，当前面有LVS，并且采用的是NAT机制时，开启tcp_tw_recycle会造成一些异常，可见： http://www.pagefault.info/?p=416。如果这种情况下仍然需要开启此选项，那么可以考虑设置net.ipv4.tcp_timestamps=0，忽略掉报文的时间戳即可。

此外，还可以通过优化tcp/ip的可使用端口的范围，进一步提升负载能力。，如下：

• net.ipv4.tcp_keepalive_time = 1200 //表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为20分钟。
• net.ipv4.ip_local_port_range = 10000 65000 //表示用于向外连接的端口范围。缺省情况下很小：32768到61000，改为10000到65000。（注意：这里不要将最低值设的太低，否则可能会占用掉正常的端口！）
• net.ipv4.tcp_max_syn_backlog = 8192 //表示SYN队列的长度，默认为1024，加大队列长度为8192，可以容纳更多等待连接的网络连接数。
• net.ipv4.tcp_max_tw_buckets = 5000 //表示系统同时保持TIME_WAIT的最大数量，如果超过这个数字，TIME_WAIT将立刻被清除并打印警告信息。默认为180000，改为5000。对于Apache、Nginx等服务器，上几行的参数可以很好地减少TIME_WAIT套接字数量，但是对于Squid，效果却不大。此项参数可以控制TIME_WAIT的最大数量，避免Squid服务器被大量的TIME_WAIT拖死。

2.4 应用服务器配置

说到应用服务器配置，这里需要提到应用服务器的几种工作模式,也叫并发策略。

• multi process:多进程方式，一个进程处理一个请求。
• prefork：类似于多进程的方式，但是会预先fork出一些进程供后续使用，是一种进程池的理念。
• worker：一个线程对应一个请求，相比多进程的方式，消耗资源变少，但同时一个线程的崩溃会引起整个进程的崩溃，稳定性不如多进程。
• master/worker：采用的是非阻塞IO的方式，只有两种进程：worker和master,master负责worker进程的创建、管理等，worker进程采用基于事件驱动的多路复用IO处理请求。mater进程只需要一个，woker进程根据cpu核数设置数目。

前三者是传统应用服务器apache和tomcat采用的方式，最后一种是nginx采用的方式。当然这里需要注意的是应用服务器和nginx这种做反向代理服务器（暂且忽略nginx+cgi做应用服务器的功能）的区别。应用服务器是需要处理应用逻辑的，有时候是耗cup资源的；而反向代理主要用作IO，是IO密集型的应用。使用事件驱动的这种网络模型，比较适合IO密集型应用，而并不适合CPU密集型应用。对于后者，多进程/线程则是一个更好地选择。

当然，由于nginx采用的基于事件驱动的多路IO复用的模型，其作为反向代理服务器时，可支持的并发是非常大的。淘宝tengine团队曾有一个测试结果是“24G内存机器上，处理并发请求可达200万”。

2.4.1 nginx/tengine

ngixn是目前使用最广泛的反向代理软件，而tengine是阿里开源的一个加强版nginx,其基本实现了nginx收费版本的一些功能，如：主动健康检查、session sticky等。对于nginx的配置，需要注意的有这么几点：

• worker数目要和cpu（核）的数目相适应
• keepalive timout要设置适当
• worker_rlimit_nofile最大文件描述符要增大
• upstream可以使用http 1.1的keepalive

典型配置可见： https://github.com/superhj1987/awesome-config/blob/master/nginx/nginx.conf

2.4.2 tomcat

tomcat的关键配置总体上有两大块：jvm参数配置和connector参数配置。

• jvm参数配置：
  • 堆的最小值：Xms
  • 堆的最大值：Xmx
  • 新生代大小: Xmn
  • 永久代大小: XX:PermSize：
  • 永久代最大大小: XX:MaxPermSize：
  • 栈大小：-Xss或-XX:ThreadStackSize

  这里对于栈大小有一点需要注意的是：在Linux x64上ThreadStackSize的默认值就是1024KB，给Java线程创建栈会用这个参数指定的大小。如果把-Xss或者-XX:ThreadStackSize设为0，就是使用“系统默认值”。而在Linux x64上HotSpot VM给Java栈定义的“系统默认”大小也是1MB。所以普通Java线程的默认栈大小怎样都是1MB。这里有一个需要注意的地方就是java的栈大小和之前提到过的操作系统的操作系统栈大小（ulimit -s）：这个配置只影响进程的初始线程；后续用pthread_create创建的线程都可以指定栈大小。HotSpot VM为了能精确控制Java线程的栈大小，特意不使用进程的初始线程（primordial thread）作为Java线程。

  其他还要根据业务场景，选择使用那种垃圾回收器，回收的策略。另外，当需要保留GC信息时，也需要做一些设置。

  典型配置可见： https://github.com/superhj1987/awesome-config/blob/master/tomcat/java_opts.conf

• connector参数配置
  • protocol: 有三个选项：bio；nio；apr。建议使用apr选项，性能为最高。
  • connectionTimeout：连接的超时时间
  • maxThreads：最大线程数，此值限制了bio的最大连接数
  • minSpareThreads: 最大空闲线程数
  • acceptCount：可以接受的最大请求数目（未能得到处理的请求排队）
  • maxConnection: 使用nio或者apr时，最大连接数受此值影响。

  典型配置可见： https://github.com/superhj1987/awesome-config/blob/master/tomcat/connector.conf

  一般的当一个进程有500个线程在跑的话，那性能已经是很低很低了。Tomcat默认配置的最大请求数是150。当某个应用拥有250个以上并发的时候，应考虑应用服务器的集群。

  另外，并非是无限调大maxTreads和maxConnection就能无限调高并发能力的。线程越多，那么cpu花费在线程调度上的时间越多，同时，内存消耗也就越大，那么就极大影响处理用户的请求。受限于硬件资源，并发值是需要设置合适的值的。

对于tomcat这里有一个争论就是： 使用大内存tomcat好还是多个小的tomcat集群好？（针对64位服务器以及tomcat来说）

其实，这个要根据业务场景区别对待的。通常，大内存tomcat有以下问题：

• 一旦发生full gc，那么会非常耗时
• 一旦gc，dump出的堆快照太大，无法分析

因此，如果可以保证一定程度上程序的对象大部分都是朝生夕死的，老年代不会发生gc,那么使用大内存tomcat也是可以的。但是在伸缩性和高可用却比不上使用小内存（相对来说）tomcat集群。

使用小内存tomcat集群则有以下优势：

• 可以根据系统的负载调整tc的数量，以达到资源的最大利用率，
• 可以防止单点故障。

2.4.3 数据库

mysql

mysql是目前最常用的关系型数据库，支持复杂的查询。但是其负载能力一般，很多时候一个系统的瓶颈就发生在mysql这一点，当然有时候也和sql语句的效率有关。比如，牵扯到联表的查询一般说来效率是不会太高的。

影响数据库性能的因素一般有以下几点：

• 硬件配置：这个无需多说
• 数据库设置：max_connection的一些配置会影响数据库的连接数
• 数据表的设计：使用冗余字段避免联表查询；使用索引提高查询效率
• 查询语句是否合理：这个牵扯到的是个人的编码素质。比如，查询符合某个条件的记录，我见过有人把记录全部查出来，再去逐条对比
• 引擎的选择：myisam和innodb两者的适用场景不同，不存在绝对的优劣

抛开以上因素，当数据量单表突破千万甚至百万时（和具体的数据有关），需要对mysql数据库进行优化，一种常见的方案就是分表：

• 垂直分表：在列维度的拆分
• 水平分表：行维度的拆分

此外，对于数据库，可以使用读写分离的方式提高性能，尤其是对那种读频率远大于写频率的业务场景。这里一般采用master/slave的方式实现读写分离，前面用程序控制或者加一个proxy层。可以选择使用MySQL Proxy，编写lua脚本来实现基于proxy的mysql读写分离；也可以通过程序来控制，根据不同的sql语句选择相应的数据库来操作，这个也是笔者公司目前在用的方案。由于此方案和业务强绑定，是很难有一个通用的方案的，其中比较成熟的是阿里的TDDL，但是由于未全部开源且对其他组件有依赖性，不推荐使用。

现在很多大的公司对这些分表、主从分离、分布式都基于mysql做了自己的二次开发，形成了自己公司的一套分布式数据库系统。比如阿里的 Cobar、网易的DDB、360的Atlas等。当然，很多大公司也研发了自己的mysql分支，比较出名的就是姜承尧带领研发的In NoSQL。

redis

当然，对于系统中并发很高并且访问很频繁的数据，关系型数据库还是不能妥妥应对。这时候就需要缓存数据库出马以隔离对mysql的访问,防止mysql崩溃。

其中，redis是目前用的比较多的缓存数据库（当然，也有直接把redis当做数据库使用的）。redis是单线程基于内存的数据库，读写性能远远超过mysql。一般情况下，对redis做读写分离主从同步就可以应对大部分场景的应用。但是这样的方案缺少ha，尤其对于分布式应用，是不可接受的。目前，redis集群的实现方案有以下几个：

• redis cluster:这是一种去中心化的方案，是redis的官方实现。是一种非常“重”的方案，已经不是Redis单实例的“简单、可依赖”了。目前应用案例还很少，貌似国内的芒果台用了，结局不知道如何。
• twemproxy：这是twitter开源的redis和memcached的proxy方案。比较成熟，目前的应用案例比较多，但也有一些缺陷，尤其在运维方面。比如无法平滑的扩容/缩容，运维不友好等。
• codis: 这个是豌豆荚开源的redis proxy方案，能够兼容twemproxy，并且对其做了很多改进。由豌豆荚于2014年11月开源，基于Go和C开发。现已广泛用于豌豆荚的各种Redis业务场景。现在比Twemproxy快近100%。目前据我所知除了豌豆荚之外，hulu也在使用这套方案。当然，其升级项目 reborndb号称比codis还要厉害。

2.5 系统架构

影响性能的系统架构一般会有这几方面：

• 负载均衡
• 同步 or 异步
• 28原则

2.5.1 负载均衡

负载均衡在服务端领域中是一个很关键的技术。可以分为以下两种：

• 硬件负载均衡
• 软件负载均衡

其中，硬件负载均衡的性能无疑是最优的，其中以F5为代表。但是，与高性能并存的是其成本的昂贵。所以对于很多初创公司来说，一般是选用软件负载均衡的方案。

软件负载均衡中又可以分为四层负载均衡和七层负载均衡。 上文在应用服务器配置部分讲了nginx的反向代理功能即七层的一种成熟解决方案，主要针对的是七层http协议（虽然最新的发布版本已经支持四层负载均衡）。对于四层负载均衡，目前应用最广泛的是lvs。其是阿里的章文嵩博士带领的团队所研发的一款linux下的负载均衡软件，本质上是基于iptables实现的。分为三种工作模式：

• NAT: 修改数据包destination ip，in和out都要经过lvs。
• DR：修改数据包mac地址，lvs和realserver需要在一个vlan。
• IP TUUNEL：修改数据包destination ip和源ip，realserver需要支持ip tunnel协议。lvs和realserver不需要在一个vlan。

三种模式各有优缺点，目前还有阿里开源的一个FULL NAT是在NAT原来的DNAT上加入了SNAT的功能。

此外，haproxy也是一款常用的负载均衡软件。但限于对此使用较少，在此不做讲述。

2.5.2 同步 or 异步

对于一个系统，很多业务需要面对使用同步机制或者是异步机制的选择。比如，对于一篇帖子，一个用户对其分享后，需要记录用户的分享记录。如果你使用同步模式（分享的同时记录此行为），那么响应速度肯定会受到影响。而如果你考虑到分享过后，用户并不会立刻去查看自己的分享记录，牺牲这一点时效性，可以先完成分享的动作，然后异步记录此行为，会提高分享请求的响应速度（当然，这里可能会有事务准确性的问题）。有时候在某些业务逻辑上，在充分理解用户诉求的基础上，是可以牺牲某些特性来满足用户需求的。

这里值得一提的是，很多时候对于一个业务流程，是可以拆开划分为几个步骤的，然后有些步骤完全可以异步并发执行，能够极大提高处理速度。

2.5.3 28原则

对于一个系统，20%的功能会带来80%的流量。这就是28原则的意思，当然也是我自己的一种表述。因此在设计系统的时候，对于80%的功能，其面对的请求压力是很小的，是没有必要进行过度设计的。但是对于另外20%的功能则是需要设计再设计、reivew再review，能够做负载均衡就做负载均衡，能够缓存就缓存，能够做分布式就分布式，能够把流程拆开异步化就异步化。

当然，这个原则适用于生活中很多事物。

三. 一般架构

一般的Java后端系统应用架构如下图所示：LVS+Nginx+Tomcat+MySql/DDB+Redis/Codis

其中，虚线部分是数据库层，采用的是主从模式。也可以使用redis cluster(codis等)以及mysql cluster(Cobar等)来替换。

相关文章

• Tomcat 生产服务器性能优化
• 如何查看HotSpot VM的运行时数据
• 浅谈HotSpot逃逸分析
• java中针对Reference的实现和相应的执行过程
• gc过程中reference对象的处理
• JVM类加载的那些事
• Tomcat5.5(6.0)配置-多域名绑定和虚拟目录
• Java反射在JVM的实现
• 粗浅看 Tomcat系统架构分析
• 粗浅看 Tomcat中设计模式分析

来了唯品会一年多，不少时间花在与服务化框架、业务应用的性能的缠斗上。

前几天正好趁着中生代社区的 十月十城技术沙龙，把脑海中 关于性能优化的记忆全部理了一遍….讲完回家，又本着认真严谨的态度再理了一遍，终于成为现在这份 58页的PPT。

范围

应用性能，受操作系统参数，三方类库选择，数据库查询，甚至压测工具如JMeter本身调优的影响。

本次分享只着重在三方面：

• JVM的调优
• 代码的调优
• 定位性能问题的工具

基本原则

网上如此多新旧不一的资料，这么多肆意传播亦真亦错的观点，怎么办呢？

1. 多看一些靠谱的资料，问一些靠谱的人。
2. 怀疑一切，微基准测试一切，诚意推荐JMH。
3. 看JDK代码，看一切代码。

JVM优化

首先，JIT入门知识；然后，JVM参数的简介；再然后，最头痛的GC问题的处理。

代码优化

代码优化，两大方向一是面向GC的编程，二是并发与锁，然后再来聊聊其他。

问题定位工具集

黑盒调优是最不可靠的，推荐线下用JMC，线上用Btrace定位问题。

特别鸣谢

感谢 R大 ， 日常三更半夜跨洋热心解答各种JVM问题。

感谢Chembo(国钦)，对PPT的美化。

完整PPT下载

《Java性能优化指南 V1.3.pdf》 by 江南白衣

百度网盘备用链接

相关文章

• 什么是Java对象分配率？
• Java 自动装箱性能
• 谁在关心toString的性能？
• 10种简单的Java性能优化
• 优化Java中的多态代码
• Spring / Hibernate应用性能调优
• 九大工具助你玩转Java性能优化
• Spring/Hibernate应用性能调优
• Java性能小技巧
• 图解 & 深入浅出JavaWeb：事务必会必知

写在之前的话，最近一年多来几乎没更新博客，更多的原因是自知资历尚潜，要学习的东西太多，要接触的东西也太多，没有足够的精力投入到博客上，或许有一天时机成熟会再提高更新频率吧，但有一点不会变的是，学习的路上数十年如一日，我会一直坚持，争取有更多的机会可以走出来，但前提是我有了足够的深度和广度。

谢谢大家的支持。

——————————————————————————————————————————————————————————-
从今年一月份开始，我们团队陆续完成了邮件服务的架构升级。新平台上线运行的过程中也发生了一系列的性能问题，即使很多看起来来微不足道的点也会让整个系统运行得不是那么平稳，今天就将这段时间的问题以及解决方案统一整理下，希望能起到抛砖的作用，让读者在遇到类似问题的时候能多一个解决方案。

新平台上线后第一版架构如下：

整个平台的数据流程是：

1. 数据通过MQ消息和远程服务调用进入新平台；
2. 通过生产平台生成邮件发送任务数据，同步Push进Redis队列中；
3. 发送平台轮询Redis队列并Pull消息到本地，然后连接邮件服务商服务器进行邮件发送，发送完毕后将结果更新回数据库；
4. 有一个全局的Checker扫表，将待发送的邮件任务投递到Redis队列中（包括发送失败，需要重试的任务）。

这版架构上线后，我们遇到的第一个问题：数据库读写压力过大后影响整体服务稳定。

表现为：

1. 数据库主库压力高，同时伴有大量的读，写操作。
2. 远程服务接口性能不稳定，业务繁忙时数据库的插入操作延迟升高，接口响应变慢，接口监控频繁报警，影响业务方。

经过分析后，我们做了如下优化：

1. 数据库做读写分离，将Checker的扫表操作放到从库上去（主从库中的同步延迟不影响我们发送，这次扫描不到的下次扫表到即可，因为每条邮件任务上有版本号控制，所以也不担心会扫描到“旧记录”的问题）。
2. 将Push到Redis的操作变成批量+异步的方式,减少接口同步执行逻辑中的操作，主库只做最简单的单条数据的Insert和Update，提高数据库的吞吐量，尽量避免因为大量的读库请求引起数据库的性能波动。

这么做还有一个原因是经过测试，对于Redis的lpush命令来说每次Push1K大小的元素和每次Push20K的元素耗时没有明显增加。

因此，我们使用了EventDrieven模型将Push操作改成了定时+批量+异步的方式往Redis Push邮件任务,这版优化上线后数据库主库CPU利用率基本在5%以下。

总结：这次优化的经验可以总结为：用异步缩短住业务流程 +用批量提高执行效率+数据库读写分离分散读写压力。

优化后的架构图：

优化上线后，我们又遇到了第二个问题：JVM假死。

表现为：

1. 单位时间内JVM Full GC次数明显升高，GC后内存居高不下，每次GC能回收的内存非常有限。
2. 接口性能下降，处理延迟升高到几十秒。
3. 应用基本不处理业务。
4. JVM进程还在，能响应jmap,jstack等命令。
5. jstack命令看到绝大多数线程处于block状态。

堆信息大致如下(注意红色标注的点):

如上两图，可以看到RecommendGoodsService 类占用了60%以上的内存空间，持有了34W个 “邮件任务对象”，非常可疑。

分析后发现制造平台在生成“邮件任务对象”后使用了异步队列的方式处理对象中的推荐商品业务，因为某个低级的BUG导致处理队列的线程数只有5个，远低于预期数量， 因此队列长度剧增导致的堆内存不够用，触发JVM的频繁GC,导致整个JVM大量时间停留在”stop the world ” 状态，JVM响应变得非常慢，最终表现为JVM假死，接口处理延迟剧增。

总结：

1. 我们要尽量让代码对GC友好，绝大部分时候让GC线程“短，平，快”的运行并减少Full GC的触发机率。
2. 我们线上的容器都是多实例部署的，部署前通常也会考虑吞吐量问题，所以JVM直接挂掉一两台并不可怕，对于业务的影响也有限，但JVM的假死则是非常影响系统稳定性的，与其奈活，不如快死!

相信很多团队在使用线程池异步处理的时候都是使用的无界队列存放Runnable任务的，此时一定要非常小心，无界意味着一旦生产线程快于消费线程，队列将快速变长，这会带来两个非常不好的问题：

1. 从线程池到无界队列到无界队列中的元素全是强引用，GC无法释放。
2. 队列中的元素因为等不到消费线程处理，会在Young GC几次后被移到年老代，年老代的回收则是靠Full GC才能回收，回收成本非常高。

经过一段时间的运行，我们将JVM内存从2G调到了3G，于是我们又遇到了第三个问题：内存变大的烦恼

JVM内存调大后，我们的JVM的GC次数减少了非常多，运行一段时间后加上了很多新功能，为了提高处理效率和减少业务之间的耦合，我们做了很多异步化的处理。更多的异步化意味着更多的线程和队列，如上述经验，很多元素被移到了年老代去，内存越用越小，如果正好在业务量不是特别大时，整个堆会呈现一个“稳步上升”的态势，下一步就是内存阀值的持续报警了。

所以，无界队列的使用是需要非常小心的。

我们把邮件服务分为生产邮件和促销邮件两部分，代码90%是复用的，但独立部署，独立的数据库，促销邮件上线后，我们又遇到了老问题：数据库主库压力再次CPU100%

在经过生产邮件3个月的运行及优化后，我们对代码做了少许的改动用于支持促销邮件的发送，促销的业务可以概括为：瞬间大量数据写入，Checker每次需要扫描上百万的数据，整个系统需要在大量待发送数据中维持一个较稳定的发送速率。上线后，数据库又再次报出异常：

1. 主库的写有大量的死锁异常（原来的生产邮件就有，不过再促销邮件的业务形态中影响更明显）。
2. 从库有大量的全表扫描，读压力非常高。

死锁的问题，原因是这样的：

条件1.如果有Transaction1需要对ABC记录加锁，已经对A，B记录加了X锁，此刻在尝试对C记录枷锁。

条件2.如果此前Transaction2已经对C记录加了独占锁，此刻需要对B记录加X锁。

就会产生dead lock。实际情况是：如果两条update语句同一时刻既需要扫描ABC又需要扫描DCB，那么死锁就出现了。

尽管Mysql做了优化，比如增加超时时间：innodb_lock_wait_timeout，超时后会自动释放，释放的结果是Transaction1和Transaction2全部Rollback（死锁问题并没有解决，如果不幸，下次执行还会重现）。再如果每个Transaction都是update数万，数十万的记录（我们的业务就是），那事务的回滚代价就非常高了。

解决办法很多，比如先select出来再做逐条做update,或者update加上一个limit限制每次的更新次数，同时避免两个Transaction并发执行等等。我们选择了第一种，因为我们的业务对于时间上要求并不高，可以“慢慢做”。

全表扫表的问题发生在Checker上，我们封装了很多操作邮件任务的逻辑在不同的Checker中，比如：过期Checker，重置Checker，Redis Push Checker等等。他们负责将邮件任务更新为业务需要的各种状态，大部分时候他们是并行执行的，会产生很多select请求。严重时，读库压力基本维持在95%上长达数小时。

全表扫描99%的原因是因为select没有使用索引，所以往往开发同学的第一反应是加索引，然后让数据库“死扛”读压力 ，但索引是有成本的，占用硬盘空间不说，insert/delete操作都需要维护索引，

其实我们还有另外好几种方案可以选择，比如：是不是需要这么频繁的执行select? 是不是每次都要select这么多数据？是不是需要同一时间并发执行？

我们的解决办法是：合理利用索引+降低扫描频率+扫描适量记录。

首先，将Checker里的SQL统一化，每个Checker产生的SQL只有条件不同，使用的字段基本一样，这样可以很好的使用索引。

其次，我们发现发送端的消费能力是整个邮件发送流程的制约点，消费能力决定了某个时间内需要多少邮件发送任务，Checker扫描的量只要刚刚够发送端满负荷发送就可以了，因此，Checker不再每个几分钟扫表一次，只在队列长度低于某个下限值时才扫描，

并且一次扫描到队列的上限值，多一个都不扫。

经过以上优化后，促销的库也没有再报警了。

直到两周以前，我们又遇到了一个新问题：发送节点CPU100%.

这个问题的表象为：CPU正常执行业务时保持在80%以上，高峰时超过95%数小时。监控图标如下：

在说这个问题前，先看下发送节点的线程模型：

Redis中根据目标邮箱的域名有一到多个Redis队列，每个发送节点有一个跟目标邮箱相对应的FetchThread用于从Redis Pull邮件发送任务到发送节点本地，然后通过一个BlockingQueue将任务传递给DeliveryThread,DeliveryThread连接具体邮件服务商的服务器发送邮件。考虑到每次连接邮件服务商的服务器是一个相对耗时的过程，因此同一个域名的DeliveryThread有多个，是多线程并发执行的。

既然表象是CPU100%,根据这个线程模型，第一步怀疑是不是线程数太多，同一时间并发导致的。查看配置后发现线程数只有几百个，同时一时间执行的只有十多个，是相对合理的，不应该是引起CPU100%的根因。

但是在检查代码时发现有这么一个业务场景：

1. 由于JIMDB的封装，发送平台采用的是轮询的方式从Redis队列中Pull邮件发送任务，Redis队列为空时FetchThread会sleep一段时间，然后再检查。
2. 从业务上说网易+腾讯的邮件占到了整个邮件总量的70%以上，对非前者的FetchThread来说，Pull不到几率非常高。

那就意味着发送节点上的很多FetchThread执行的是不必要的唤醒->检查->sleep的流程，白白的浪费CPU资源。

于是我们利用事件驱动的思想将模型稍稍改变一下：

每次FetchThread对应的Redis队列为空时，将该线程阻塞到Checker上，由Checker统一对多个Redis队列的Pull条件做判断，符合Pull条件后再唤醒FetchThread。

Pull条件为：

1.FetchThread的本地队列长度小于初始长度的一半。

2.Redis队列不为空。

同时满足以上两个条件，视为可以唤醒对应的FetchThread。

以上的改造本质上还是在降低线程上下文切换的次数，将简单工作归一化，并将多路并发改为阻塞+事件驱动和降低拉取频率，进一步减少线程占用CPU的时间片的机会。

上线后，发送节点的CPU占用率有了20%左右的下降，但是并没有直接将CPU的利用率优化为非常理想的情况（20%以下），我们怀疑并没有找到真正的原因。

于是我们接着对邮件发送流程做了进一步的梳理，发现了一个非常奇怪的地方，代码如下：

我们在发送节点上使用了Handlebars做邮件内容的渲染，在初始化时使用了Concurrent相关的Map做模板的缓存，但是每次渲染前却要重新new一个HandlebarUtil，那每个HandlebarUtil岂不是用的都是不同的TemplateCache对象？既然如此，为什么要用Concurrent(意味着线程安全)的Map？

进一步阅读源码后发现无论是Velocity还是Handlebars在渲染先都需要对模板做语法解析，构建抽象语法树（AST），直至生成Template对象。构建的整个过程是相对消耗计算资源的，因此猜想Velocity或者Handlebars会对Template做缓存，只对同一个模板解析一次。

为了验证猜想，可以把渲染的过程单独运行下：

可以看到Handlebars的确可以对Template做了缓存，并且每次渲染前会优先去缓存中查找Template。而除了同样执行5次，耗时开销特别大以外，CPU的开销也同样特别大，上图为使用了缓存CPU利用率，下图为没有使用到缓存的CPU利用率：

找到了原因，修改就比较简单了保证handlebars对象是单例的，能够尽量使用缓存即可。

上线后结果如下：

至此，整个性能优化工作已经基本完成了，从每个案例的优化方案来看，有以下几点经验想和大家分享：

1. 性能优化首先应该定位到真正原因，从原因下手去想方案。
2. 方案应该贴合业务本身，从客观规律、业务规则的角度去分析问题往往更容易找到突破点。
3. 一个细小的问题在业务量巨大的时候甚至可能压垮服务的根因，开发过程中要注意每个细节点的处理。
4. 平时多积累相关工具的使用经验，遇到问题时能结合多个工具定位问题。

相关文章

• Java性能优化指南，及唯品会的实战
• 什么是Java对象分配率？
• Java 自动装箱性能
• 谁在关心toString的性能？
• 10种简单的Java性能优化
• 优化Java中的多态代码
• Spring / Hibernate应用性能调优
• 九大工具助你玩转Java性能优化
• Spring/Hibernate应用性能调优
• Java性能小技巧

嗯，这篇不长的文章，是一个晚上工作到三点的血泪加班史总结而成。多一个读，可能就少一个人加班。

《 TLS协议分析 与 现代加密通信协议设计》 首先要感谢这篇文章，如果没有它，我可能还要花更多的时间才能完成。文章有点长，能看多少是多少，每句都是收获。

1.背景知识

1.1 协议史

1996: SSL3.0. 写成RFC，开始流行。目前(2015年)已经不安全，必须禁用。

1999: TLS1.0. 互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006: TLS1.1. 作为 RFC 4346 发布。主要fix了CBC模式相关的如BEAST攻击等漏洞。

2008: TLS1.2. 作为RFC 5246发布 。增进安全性，目前的主流版本。

2015之后: TLS 1.3，还在制订中。

1.2 TLS算法组合

在TLS中，5类算法组合在一起，称为一个CipherSuite：

• 认证算法
• 加密算法
• 消息认证码算法 简称MAC
• 密钥交换算法
• 密钥衍生算法

比较常见的算法组合是 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 和  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256， 都是ECDHE 做密钥交换，使用RSA做认证，SHA256做PRF算法。

一个使用AES128-CBC做加密算法，用HMAC做MAC。

一个使用AES128-GCM做加密算法，MAC由于GCM作为一种AEAD模式并不需要。

两者的差别，在于 Block Cipher+HMAC 类的算法都爆出了各种漏洞，下一代的TLS v1.3干脆只保留了Authenticated-Encryption 类的算法，主要就是AES-GCM，AEAD模式（Authenticated-Encryption With Addtional data）里Encrypt和MAC直接集成为一个算法，在算法内部解决好安全问题。

1.3 Java 对SSL的支持

JDK7的client端只支持TLS1.0，服务端则支持TLS1.2。

JDK8完全支持TLS1.2。

JDK7不支持GCM算法。

JDK8支持GCM算法，但性能极差极差极差，按Netty的说法：

•  Java 8u60以前多版本，只能处理1 MB/s。
•  Java 8u60 开始，10倍的性能提升，10-20 MB/s。
•  但比起 OpenSSL的 ~200 MB/s，还差着一个量级。

1.4 Netty 对SSL的支持

Netty既支持JDK SSL，也支持Google的boringssl， 这是OpenSSL 的一个fork，更少的代码，更多的功能。

依赖netty-tcnative-boringssl-static-linux-x86_64.jar即可，它里面已包含了相关的so文件，再也不用管Linux里装没装OpenSSL，OpenSSL啥版本了。

2. 性能问题的出现及调优

2.1 性能问题的出现

忘掉前面所有的背景知识，重新来到问题现场：

JDK7的JMeter HTTPS客户端，连接JDK8的Netty服务端时，速度还可以。

JDK8的JMeter HTTPS客户端，则非常慢，非常慢，非常吃客户端的CPU。

按套路，在JMeter端增加启动参数 -Djavax.net.debug=ssl,handshake  debug 握手过程。

(OpenSSL那边这个参数加了没用)

*** ClientHello, TLSv1.2，可以看到，Client端先发起协商，带了一堆可选协议

Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256…]

*** ServerHello, TLSv1.2 然后服务端回选定一个

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

还可以看到，传输同样的数据，不同客户端/服务端组合下有不同的纪录：

Client: JDK7 JDK SSL ＋ Server: JDK7/8 JDK SSL

**TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

WRITE: TLSv1 Application Data, length = 32

WRITE: TLSv1 Application Data, length = 304

READ:  TLSv1 Application Data, length = 32

READ:  TLSv1 Application Data, length = 96

READ:  TLSv1 Application Data, length = 32

READ:  TLSv1 Application Data, length = 10336

Client: JDK8 JDK SSL ＋ Server: JDK8 Open SSL

** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Thread Group 1-1, WRITE: TLSv1.2 Application Data, length = 300

Thread Group 1-1, READ: TLSv1.2 Application Data, length = 92

Thread Group 1-1, READ: TLSv1.2 Application Data, length = 10337

2.2 原因分析

带着上面的记录，经过一晚的奋战，得出了文章一开始的背景信息，再回头分析就很好理解了，JMeter Https 用的是JDK8 SSL，很不幸的和服务端的OpenSSL协商出一个JDK8实现超慢的TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。

对于服务端/客户端都是基于Netty ＋ boringssl的RPC框架，使用TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 仍然是好的，毕竟更安全。

但Https接口，如果不确定对端的是什么，JDK7 SSL or JDK8 SSL or OpenSSL，为免协商出一个超慢的GCM算法，Server端需要通过配置，才决定要不要把GCM放进可选列表里。

2.3 实现

经过一轮学习，平时是这样写的：

SslContext sslContext = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey())  .sslProvider( SslProvider. OPENSSL).build();

如果想不要开GCM，那把ReferenceCountedOpenSslContext里面的DEFAULT_CIPHERS抄出来，删掉两个GCM的。

List<String> ciphers = Lists.newArrayList(“ECDHE-RSA-AES128-SHA”, “ECDHE-RSA-AES256-SHA”, “AES128-SHA”, “AES256-SHA”, “DES-CBC3-SHA”);

SslContext sslContext = SslContextBuilder.forServer(ssc.certificate(), ssc.privateKey())                               .sslProvider( SslProvider. OPENSSL).ciphers(ciphers).build();

3 结论

• OpenSSL(boringssl)在我们的测试用例里，比JDK SSL 快10倍，10倍!!! 所以Netty下尽量都要使用OpenSSL。
• 在确定两端都使用OpenSSL时，TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 仍然是好的，毕竟更安全，也是主流。
• 对端如果是JDK8 SSL时，Server端要把GCM算法从可选列表里拿掉。

可能感兴趣的文章

• 类加载器的工作原理
• Java方法参数太多怎么办—Part5—方法命名
• 细话Java：”失效”的private修饰符
• 写Java也得了解CPU–CPU缓存
• Jsoup代码解读（7）：实现一个CSS Selector
• Java7里try-with-resources分析
• java/android 设计模式学习笔记（6）：适配器模式
• ThreadLocal 那点事儿（续集）
• 盘点当下最流行的 Java 工具
• Java并发编程：CountDownLatch、CyclicBarrier和 Semaphore

背景

前几天在项目上线过程中，发现有一个页面无法正确获取数据，经排查原来是接口调用超时，而最后发现是因为SQL查询长达到20多秒而导致了问题的发生。

这里，没有高深的理论或技术，只是备忘一下经历和解读一些思想误区。

复杂SQL语句的构成

这里不过多对业务功能进行描述，但为了突出问题所在，会用类比的语句来描述当时的场景。复杂的SQL语句可以表达如下：

SELECT * FROM a_table AS a 
LEFT JOIN b_table AS b ON a.id=b.id 
WHERE a.id IN (
    SELECT DISTINCT id FROM a_table 
    WHERE user_id IN (100,102,103) GROUP BY user_id HAVING count(id) > 3
)

关联查询

从上面简化的SQL语句，可以看出，首先进行的是关联查询。

子查询

其次，是嵌套的子查询。此子查询是为了找出多个用户共同拥有的组ID。所以语句中的“100,102,103”是根据场景来定的，并且需要和后面“count(id) > 3”的个数对应。简单来说，就是找用户交集的组ID。

耗时在哪？

假设现在a_table表的数据量为20W，而b_table的数据量为2000W。大家可以想一下，你觉得主要的耗时是在关联查询部分，还是在子查询部分？

（思考空间。。。。）

（思考空间。。。。 。。。）

（思考空间。。。。 。。。 。。。）

问题定位

对于SQL底层的原理和高深的理论，我暂时掌握不够深入。但我知道可以通过类比和简单的测试来验证是哪一块环节出了问题。

初步断定

首先，对于只有一个用户ID时，我会把上面的语句简化成：

SELECT * FROM a_table AS a 
LEFT JOIN b_table AS b ON a.id=b.id 
WHERE user_id IN (100)

所以，初步断定应该是嵌套的子查询部分占用了大部分的时间。

再进一步验证

既然定位到了是嵌套的子查询语句的问题，那又要分为两块待排查的区域：是子查询本身耗时大，还是嵌套而导致慢查询？

结果很容易发现，当我把子查询单独在DB中执行时，是非常快的。所以排除。

剩下的不言而喻， 20秒的慢查询是嵌套引起的。

但因为处于上线紧急的过程中，为了确保，我快速地验证了我的结论：

1、将子查询的ID单独执行，并把得到的结果序列手动拼成一段ID，如：1,2,3,4, … , 999

2、将上面得到的序列ID，手动替换到原来的SQL语句

3、执行，发现，很快！只用了约 150 ms

Well Done!  准备修复上线！

解决方案

线上的问题，很多时间都是在定位问题和分析原因，既然问题找到了，原因也找到了，解决方案不言而喻。代码简单处理即可。

另外一个需要注意的点

当前，实际的SQL语句，会比这个更为复杂，但已足以表达问题所在。但在前期，笔者也做了一些SQL的代码。

因为b_table比a_table大，所以一开始 b_table 左关联 a_table 时，很慢，大概是1秒多，而且数据量是很少的；但若反过来，a_table 左关联 b_table 时，则很快，大概是100毫秒。

所以，又发现一个有趣的现象：

大表 左关联 小表，很慢；小表 左关联 大表，很快。

当然，这些我们理论上都知道，但实际开发会忘却。又或者一开始两个表都为空时，而又没考虑到后期这两个表增长的速度时，日后就会埋下坑了。

总结

首先，嵌套的子查询是很慢的。

原因，我还没仔细去研究，但在下班的路上和我的同事交流时，他说曾经看过这方面相关的书籍，是说每一次的子查询都会产生一个SQL语句，所以就N次查询了。而另外一位资深的QA同事则跟我说，应该是M*N的问题。

其次，我一开始使用嵌套子查询，是存在这样一个 误区：我觉得将这些操作交给MySQL自身来处理会更高效，毕竟DB内部会有良好的机制来执行这些查询由。

然后，实际表白，我错了。因为这不是简单的合并MC批量查询。

当我们决定使用一些底层的技术时，只有当我们理解透彻了，才能使用更为恰当。而因为无知就断定工具、框架、底层无所不能时，往往就会中招。

一个20秒SQL慢查询优化的经历与处理方案，首发于 文章 - 伯乐在线。

玩过性能优化的朋友都清楚，性能优化的关键并不在于怎么进行优化，而在于怎么找到当前系统的性能瓶颈。
性能优化分为好几个层次，比如系统层次、算法层次、代码层次…JVM 的性能优化被认为是底层优化，门槛较高，精通这种技能的人比较少。笔者呆过几家技术力量不算弱的公司，每个公司内部真正能够进行 JVM 性能调优的人寥寥无几、甚至没有。如是乎，能够有效通过 JVM 调优提升系统性能的人往往被人们冠以”大牛”、”大师”之类的称呼。
其实 JVM 本身给我们提供了很多强大而有效的监控进程、分析定位瓶颈的工具，比如 JConsole、JMap、JStack、JStat 等等。使用这些命令，再结合 Linux 自身提供的一些强大的进程、线程命令，能够快速定位系统瓶颈。本文以一次使用这些工具准确定位到某系统瓶颈的实战经验为例，希望能为大家掌握 JVM 调优这项技能起到一些借鉴作用。
本文背景：

• Linux：RedHat 6.1
• Weblogic：11g
• JRokit：R28.2.4
• JDK：1.6.0_45

Weblogic 跑在 JRokit 上面，JDK 是我们对 JRokit 进行监控分析的工具。

1. LoadRunner 压测结果

该系统其实早已跑在生产上好多年，虽然没有做过压力测试，但稳定性还是可以的。公司进行架构调整，有一些新系统将对接该系统。公司领导担心对接后该系统的并发性能问题，于是开始对该系统进行并发压力测试。
50 个用户并发压十几个小时，TRT 在 20 左右，TPS 在 2.5 左右。领导对这个结果不满意，要求进行优化。但这是个老系统，开发在之前明显已经对其代码做过很多优化，如今面对这种状况也束手无策。

2. Oracle 的 awr 报告分析

有句老话，优化来优化去，系统的性能瓶颈还是会在数据库上面。在这里我们首先想到的也是数据库的问题。
并发压测的时候  Spotlight 查看数据库服务器各项性能指标，很清闲。

分析 awr 报告，结果显示也是很清闲。

并发压测的时候去相关数据表执行一些 sql 的速度很快也证明着问题不在 Oracle 这边。

3. Weblogic 服务器的性能指标

使用  Spotlight 查看并发压测时的 Weblogic 所在的 Linux 服务器，除了 CPU 之外其它各项指标显示，Linux 也很清闲。
虽然 CPU 利用率始终在 200% 左右徘徊，但这对于 16 核的系统来讲也算是正常的吧？

4. JStack 报告分析

事情到了这里，大家已经想到了线程死锁、等待的问题了。
没错，JStack 隆重登场。JStack 能够看到当前 Java 进程中每个线程的当前状态、调用栈、锁住或等待去锁定的资源，而且很强悍的是它还能直接报告是否有线程死锁，可谓解决线程问题的不二之选。
$  /opt/jdk1.6.0_45/bin/jstack -l 10495 > ~/10495jstack.txt
JRokit 堆栈的拉取，可以直接用 JDK 的 JStack，10495 是 Weblogic 服务的进程 ID。注意一定要用该进程的启动用户去拉，否则会报 Unable to open socket file: target process not responding or HotSpot VM not loaded 错误。
JStack 拉取的文件信息基本分为以下几个部分：

• 该拉取快照的服务器时间
• JVM 版本
• 以线程 ID(即 tid)升序依次列出当前进程中每个线程的调用栈
• 死锁(如果有的话)
• 阻塞锁链
• 打开的锁链
• 监视器解锁情况跟踪

每个线程在等待什么资源，这个资源目前在被哪个线程 hold，尽在眼前。JStack 最好在压测时多次获取，找到的普遍存在的现象即为线程瓶颈所在。

4.1. TLA 空间的调整

多次拉取 JStack，发现很多线程处于这个状态：
at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method)
at jrockit/vm/Allocator.allocObjectOrArray(Allocator.java:354)[optimized]
at java/util/HashMap.resize(HashMap.java:564)[inlined]
at java/util/LinkedHashMap.addEntry(LinkedHashMap.java:414)[optimized]
at java/util/HashMap.put(HashMap.java:477)[optimized]
由此怀疑出现上述堆栈的原因可能是 TLA 空间不足引起。TLA 是 thread local area 的缩写，是每个线程私有的空间，所以在多线程环境下 TLA 带来的性能提升是显而易见的。如果大部分线程的需要分配的对象都较大，可以考虑提高 TLA 空间，因为这样更大的对象可以在 TLA 中进行分配，这样就不用担心和其它线程的同步问题了。但这个也不可以调的太大，否则也会带来一些问题，比如会带来更多内存碎片、更加频繁的垃圾搜集。
TLA 默认最小大小 2 KB，默认首选大小 16 KB – 256 KB (取决于新生代分区大小)。这里我们调整 TLA 空间大小为最小 32 KB，首选 1024 KB，JVM 启动参数中加入：
-XXtlaSize:min=32k,preferred=1024k

5. JStat 结合 GC 日志报告分析

第 4 步参数生效之后继续压测，TLA 频繁申请是降下来了，但 TRT 仍旧是 20，TPS 依旧 2.5。别灰心，改一个地方就立竿见影，胜利似乎来得太快了点。
现在怀疑是服务堆内存太小，查看一下果然。服务器物理内存 32 GB，Weblogic 进程只分到了 6 GB。怎么查看？至少有四种办法：

5.1. ps 命令

$  ps -ef | grep java
defonds     29874 29819  2 Sep03 ?        09:03:17 /opt/jrockit-jdk1.6.0_33/bin/java -jrockit -Xms6000m -Xmx6000m -Dweblogic.Name=AdminServer -Djava.security.policy=

5.2. Weblogic 控制台

登录 Weblogic 管理控制台 -> 环境 -> 服务器，选择该服务器实例 -> 监视 -> 性能 -> 当前堆大小。
这个页面还能看到进程已运行时间，启动以来发生的 GC 次数，可以折算出 GC 的频率，为本次性能瓶颈 – GC 过于频繁提供有力的佐证。

5.3. GC 日志报告

开启 JRokit GC 日志报告只需在 Java 进程启动参数里加入
-Xverbose:memory -Xverboselog:verboseText.txt
GC 日志将会被输出到 verboseText.txt 文件，这个文件一般会生成在启动的 Weblogic 域目录下。如果找不着也可以用 find 命令去搜：
$  find /appserver/ -name verboseText.txt
/appserver/Oracle/Middleware/user_projects/domains/defonds_domain/verboseText.txt
GC log 拿到后，第 3 行中的 maximal heap size 即为该进程分配到的最大堆大小：
[INFO ][memory ] Heap size: 10485760KB, maximal heap size: 10485760KB, nursery size: 5242880KB.
下面还有进程启动以后较为详细的每次 GC 的信息：
[INFO ][memory ] [YC#2547] 340.828-340.845: YC 10444109KB->10417908KB (10485760KB), 0.018 s, sum of pauses 17.294 ms, longest pause 17.294 ms.
[INFO ][memory ] [YC#2548] 340.852-340.871: YC 10450332KB->10434521KB (10485760KB), 0.019 s, sum of pauses 18.779 ms, longest pause 18.779 ms.
[INFO ][memory ] [YC#2549] 340.878-340.895: YC 10476739KB->10485760KB (10485760KB), 0.017 s, sum of pauses 16.520 ms, longest pause 16.520 ms.
[INFO ][memory ] [OC#614] 340.895-341.126: OC 10485760KB->10413562KB (10485760KB), 0.231 s, sum of pauses 206.458 ms, longest pause 206.458 ms.
第一行表示该进程启动后的第 340.828 秒 – 340.845 秒期间进行了一次 young gc，该次 GC 持续了 17.294 ms，将整个已用掉的堆内存由 10444109 KB 降低到 10417908 KB。
第三行同样是一次 young gc，但该次 GC 后已用堆内存反而上升到了 10485760 KB，也就是达到最大堆内存，于是该次 young gc 结束的同时触发 full gc。
第四行是一次 old gc (即 full gc)，将已用堆内存由 10485760 KB 降到了 10413562 KB，耗时 206.458 ms。
这些日志同样能够指出当前压力下的 GC 的频率，为本次性能瓶颈 – GC 过于频繁提供有力的佐证。

5.4. JStat 报告

跟 JStack 的拉取一样，可以直接用 JDK 的 JStat 去拉取 JRokit 的 GC 信息：
$  /opt/jdk1.6.0_45/bin/jstat -J-Djstat.showUnsupported=true -snap 10495 > ~/10495jstat.txt
注意这个信息是一个快照，这是跟 GC 日志报告不同的地方。
jrockit.gc.latest.heapSize=10737418240
jrockit.gc.latest.nurserySize=23100384
上述是当前已用碓大小和新生代分区大小。多拉几次即可估算出各自分配的大小。

5.5. 内存分配

根据 5.1 – 5.4 我们得出当前服务器分配堆内存太小的结论，根据 5.3 GC 日志报告和 5.4. JStat 报告可以得出新生代分区太小的结论。
于是我们调整它们的大小，结合 4.1 TLA 调整的结论，JVM 启动参数增加以下：
-Xms10240m -Xmx10240m -Xns:1024m -XXtlaSize:min=32k,preferred=1024k
再次压测，TRT 降到了 2.5，TPS 上升到 20。

6. 性能瓶颈的定位

很明显，上述 JVM 调整没有从根本上解决性能问题，我们还没有真正定位到系统性能瓶颈。

6.1. 性能线程的定位

6.1.1. 性能进程的获取

使用 TOP 命令拿到最耗 CPU 的那个进程：

进程 ID 为 10495 的那个进程一直在占用很高的 CPU。

6.1.2. 性能线程的获取

现在我们来找到这个进程中占用 CPU 较高的那些线程：
$  ps p 10495 -L -o pcpu,pid,tid,time,tname,cmd > ~/10495ps.txt
多次拉这个快照，我们找到了 tid 为 10499、10500、10501、10502 等线程一直在占用着很高的 CPU：

拉 JStack 快照看看都是一些什么线程：
$  /opt/jdk1.6.0_45/bin/jstack -l 10495 > ~/10495jstack.txt
相关部分结果如下：
“(GC Worker Thread 1)” id=? idx=0×10 tid=10499 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None

“(GC Worker Thread 2)” id=? idx=0×14 tid=10500 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None

“(GC Worker Thread 3)” id=? idx=0×18 tid=10501 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None

“(GC Worker Thread 4)” id=? idx=0x1c tid=10502 prio=5 alive, daemon
at pthread_cond_wait@@GLIBC_2.3.2+202(:0)@0x3708c0b44a
at eventTimedWaitNoTransitionImpl+71(event.c:90)@0x7fac47be8528
at eventTimedWaitNoTransition+66(event.c:72)@0x7fac47be8593
at mmGCWorkerThread+137(gcthreads.c:809)@0x7fac47c0774a
at thread_stub+170(lifecycle.c:808)@0x7fac47cc15bb
at start_thread+208(:0)@0x3708c077e1
Locked ownable synchronizers:
- None

6.2. 找到性能瓶颈

事情到了这里，已经不难得出当前系统瓶颈就是频繁 GC。
为何会如此频繁 GC 呢？继续看 JStack，发现这两个互相矛盾的现象：
一方面 GC Worker 线程在拼命 GC，但是 GC 前后效果不明显，已用堆内存始终降不下来；
另一方面大量 ExecuteThread 业务处理线程处于 alloc_enqueue_allocation_and_wait_for_gc 的 native_blocked 阻塞状态。
此外，停止压测以后，查看已用堆内存大小，也就几百兆，不到分配堆内存的 1/10。
这说明了什么呢？这说明了我们应用里没有内存泄漏、静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象。
很明显还是代码里有问题。那么这些对象来自哪里？如何在海量业务代码里边准确定位这些性能代码？也就是说如何利用 JVM 调优驱动代码层面的调优？请参考博客《 JVM 性能调优实战之：使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码》，使用 TProfiler 我们成功找到了代码里边导致 JVM 频繁 GC 的元凶，并最终解决掉了这个性能瓶颈，将 TRT 降到了 0.5，TPS 提升至 100 +。

参考资料

• Optimizing Memory Allocation Performance
• Understanding Verbose Output

相关文章

• JVM 性能调优实战之：使用阿里开源工具 TProfiler 在海量业务代码中精确定位性能代码
• JVM监控与调优
• Java多线程面试问题集锦
• Eclipse 教程系列
• Android一周开发要闻 – 第一期字幕
• Facebook推出Android构建工具——Buck
• 谷歌最新版安卓系统“果冻豆”份额首超其他
• 微信开发之通过代理调试本地项目
• 粗浅看 java反射机制
• 2016年7款最佳 Java 框架推荐

本文是《 JVM 性能调优实战之：一次系统性能瓶颈的寻找过程》 的后续篇，该篇介绍了如何使用 JDK 自身提供的工具进行 JVM 调优将 TPS 由 2.5 提升到 20 (提升了 7 倍)，并准确定位系统瓶颈：我们应用里静态对象不是太多、有大量的业务线程在频繁创建一些生命周期很长的临时对象，代码里有问题。那么问题来了，如何在海量业务代码里边准确定位这些性能代码？本文将介绍如何使用阿里开源工具 TProfiler 来定位这些性能代码，成功解决掉了 GC 过于频繁的性能瓶颈，并最终在上次优化的基础上将 TPS 再提升了4 倍，即提升到 100。

1. TProfiler 的下载安装

1.1. 下载

访问  TProfiler 的 GitHub 主页，点击 Clone or download 按钮的打开下载选项，点击该选项下的 Download ZIP 按钮将 TProfiler-master.zip 下载到本地。笔者上传了一份截至 20160920 最新 TProfiler-master.zip 到 CSDN 资源，读者朋友也可以去这里下载： http://download.csdn.net/detail/defonds/9635731。

1.2. 安装

SSH 登录需要监控的远程服务器主机，为 TProfiler 新建安装路径：
$  mkdir /opt/tprofiler
本地将下载后的 TProfiler-master.zip 解压缩，将 dist 目录下的 profile.properties 以及 dist/lib 目录下的 tprofiler-1.0.1.jar ftp 上传到远程服务器 /opt/tprofiler 目录下。
最后将远程服务器 /opt/tprofiler 目录及其下所有文件的所有者改为启动 Weblogic 进程的用户及其所在用户组。

2. TProfiler 的配置部署

2.1. TProfiler 配置

编辑服务器 /opt/tprofiler/profile.properties 文件内容如下：
#log file name
logFileName = tprofiler.log
methodFileName = tmethod.log
samplerFileName = tsampler.log

#basic configuration items
startProfTime = 9:00:00
endProfTime = 23:00:00
eachProfUseTime = 5
eachProfIntervalTime = 50
samplerIntervalTime = 20
port = 30000
debugMode = false
needNanoTime = false
ignoreGetSetMethod = true

#file paths
logFilePath = ${user.home}/logs/${logFileName}
methodFilePath = ${user.home}/logs/${methodFileName}
samplerFilePath = ${user.home}/logs/${samplerFileName}

#include & excludes items
excludeClassLoader = org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
includePackageStartsWith =com.caucho;com.defonds;com.fasterxml;com.sun.jersey;com.sun.jmx;
org.apache;org.codehaus;org.jdbcdslog;org.mybatis;org.quartz;org.springframework
excludePackageStartsWith = com.taobao.sketch;org.apache.velocity;com.alibaba;com.taobao.forest.domain.dataobject
红色部分是我们修改后的内容，其它部分使用默认值。

2.2. Weblogic 启动参数配置

在 Weblogic JVM 启动参数里加入：
-javaagent:/opt/tprofiler/tprofiler-1.0.1.jar -Dprofile.properties=/opt/tprofiler/profile.properties
之后重启 Weblogic。

3. TProfiler 的远程操作

使用启动 Weblogic 进程的用户 SSH 远程登录正在进行压测的机器。

3.1. 查看 TProfiler 当前状态

$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 status
running
得到这个结果证明 TProfiler 正在进行采集工作。

3.2. 将 TProfiler 停止，以释放其占用的系统资源

随时关闭 TProfiler：
$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 stop
$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 status
stop
随时启动以继续采集：
$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 start
$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 status
running

3.3. 刷出数据

$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.client.TProfilerClient 127.0.0.1 30000 flushmethod
会将数据刷出到 ~/logs/ 目录下：

4. TProfiler 对性能方法的采集

4.1. 普通方法、线程统计

$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.analysis.SamplerLogAnalysis ~/logs/tsampler.log ~/logs/method.log ~/logs/thread.log

4.2. top 统计

$  java -cp /opt/tprofiler/tprofiler-1.0.1.jar com.taobao.profile.analysis.ProfilerLogAnalysis ~/logs/tprofiler.log ~/logs/tmethod.log ~/logs/topmethod.log ~/logs/topobject.log
方法执行时间统计：这个非常非常重要，这个是 TProfiler 最最重要的 feature，是其能够傲视所有其他性能测试类(包括 jvm 性能测试类)软件的关键所在，我们将会不止一次地在关键的时候受益于 TProfiler 的这一非常有用的特性。
上述命令刷出的 topmethod.log 部分结果如下：
com/defonds/core/ppts/common/support/JsonUtils:object2jsonString:123 13519 154 2083584
com/caucho/hessian/client/HessianURLConnection:sendRequest:156 15894 130 2072565
com/defonds/rest/core/client/proxy/ResourceJsonInvocationHandler:invoke:39 8123 113 921340
com/defonds/core/ppts/cache/service/impl/MerBankCfgServiceImpl:selectMerBankCfgByParams:72 54213 15 799322
com/defonds/core/ppts/incomes/biz/sinopay/service/impl/SinoPayBankReturnServiceImpl4Json:updateOrderSuccess:792 2495 176 438542
com/defonds/core/ppts/common/support/framework/bean/Message:<init>:76 6219 26 163741
com/fasterxml/jackson/databind/ser/impl/IndexedListSerializer:serializeContents:107 51883 3 145556
com/defonds/core/ppts/cache/biz/cims/impl/AccountPrdAndBankCacheImpl:selectBasicProductCfg:144 16131 8 137029
格式说明：方法信息 执行次数 平均执行时间(单位：ms) 全部执行时间(单位：ms)

5. 性能方法的优化

根据 topmethod.log 统计结果，我们拿到了热点方法 top10：

这是压测时根据多次采样结果，拣选出的一次比较有代表性的一次。红色部分值得我们去重点关注并优化一下，因为极有可能就是应用瓶颈所在。这些代码要么是导致平均响应时间低下的一些点，要么是导致大量临时对象产生的一些点。
对于上篇博客中的结论，这些代码的调优原则是：临时对象能改成静态对象进行复用就改成公用对象否则要想方设法缩短其生命周期；高频访问代码提高响应速度。根据 jvm gc 日志发现很多 young gc 之后堆内存已用空间不仅下降反而上升至最大使用量导致 full gc，临时对象如果可以和其它线程复用的话改成静态对象以减少大量线程 local 对象的产生。
以排名第一的热点方法 com/defonds/core/ppts/common/support/JsonUtils:object2jsonString:123 为例，看看如何来进行调优。

import org.codehaus.jackson.map.ObjectMapper;  
    public static <T> String object2jsonString(T t) {  
        try {  
            ObjectMapper objectMapper = instanceObjectMapper();  
            return objectMapper.writeValueAsString(t);  
        } catch (JsonParseException e) {  
            log.error(e.getMessage(), e);  
            throw new SysException(e);  
        } catch (JsonMappingException e) {  
            log.error(e.getMessage(), e);  
            throw new SysException(e);  
        } catch (IOException e) {  
            log.error(e.getMessage(), e);  
            throw new SysException(e);  
        }  
    }  
    public static ObjectMapper instanceObjectMapper() {  
        JsonFactory jf = new JsonFactory();  
        jf.configure(Feature.WRITE_NUMBERS_AS_STRINGS, true);  
        return new ObjectMapper(jf);  
    }

该热点方法的优化建议：
这个方法平均调用时间在 154ms，如果在低并发时可能比这要小得多。但是高并发时可能要等待 GC 的堆内存释放、GC 作业时对业务线程造成的暂停时间等因素影响，这个时间会被无限放大。

5.1. 临时对象改成静态对象

object2jsonString 方法的 objectMapper 对象，instanceObjectMapper 方法的 jf 对象；

5.2. json 处理由 jackson 改为 fastjson

jackson 和 spring 整合的很好，提供的功能点很多很强大。但是其性能未必靠得住。
比如我们原来用过谷歌的 Gson 进行 json 处理，某个大对象的 json 解析使用 gson 是 100 多秒，而换成 fastjson 解析后是 900 多毫秒。上百倍的性能差距呀，这还是在单用户操作、不能存在 CPU 和内存等资源限制及竞争的情况下拿到的数据。在此向贡献出 fastjson 的阿里人致敬~

5.3. 频繁 GC 的瓶颈已不复存在

针对 TProfiler 帮我们在海量业务代码中定位到的 top5 性能代码进行优化后，部署重新压测，50 个用户并发两个小时左右，我们拉了几次快照，上篇博客中定位的频繁 GC 的性能瓶颈已不复存在，TRT 也由上篇博客优化到的 2.5 下降到 0.5，TPS 基本能稳定在 100 个。问题圆满解决。

6. 需要注意的一些问题

6.1. TProfiler 端口号是否已被占用

为 TProfiler 选取端口号之前要先检测一下该端口号是否已被占用：
$  netstat -an | grep 30000

6.2. TProfiler 配置里 includePackageStartsWith

一定要根据你自己的系统进行实际更改，不然就会遇到《 TProfiler.log的内容为空 #33》的问题，截图如下：

6.3. 几个命令配合使用

在压测的时候，结合使用 start、stop、flushmethod、ProfilerLogAnalysis topmethod 等几个命令，以拿到关键性的结果。如果能再结合 Weblogic、LoadRunner 的启动、停止，效果最佳。不然的话，如果 JVM 已经跑了很多天，拿到的数据可能不是你想要的，反而会误导你南辕北辙。

7. 后记

总体来讲，TProfiler 配置部署、远程操作、日志阅读都不太复杂，操作还是很简单的。但是其却是能够起到一针见血、立竿见影的效果，帮我们解决了 GC 过于频繁的性能瓶颈。
TProfiler 最重要的特性就是能够统计出你指定时间段内 JVM 的 topmethod，这些 topmethod 极有可能就是造成你 JVM 性能瓶颈的元凶。这是其他大多数 JVM 调优工具所不具备的，包括 JRockit Mission Control。JRokit 首席开发者  Marcus Hirt 在其私人博客《 Low Overhead Method Profiling with Java Mission Control》下的评论中曾明确指出 JRMC 并不支持 TOP 方法的统计：

最后再次向具备开源精神的阿里技术团队致敬~

参考资料

• TProfiler是一个可以在生产环境长期使用的性能分析工具
• Low Overhead Method Profiling with Java Mission Control

相关文章

• JVM 性能调优实战之：一次系统性能瓶颈的寻找过程
• JVM监控与调优
• Java 面试题问与答：编译时与运行时
• Eclipse 教程系列
• Java 8新特性探究（三）解开lambda最强作用的神秘面纱
• 跟我学Spring3（7.3）：对JDBC的支持之关系数据库操作对象化
• 跟我学Spring3（9.2）：Spring的事务之事务管理器
• Java HashMap工作原理及实现
• 构建需求响应式亿级商品详情页
• 缓存穿透、缓存并发、缓存失效之思路变迁

问题

一般一个 iOS APP 做的事就是：请求数据->保存数据->展示数据，一般用 Sqlite 作为持久存储层，保存从网络拉取的数据，下次读取可以直接从 Sqlite DB 读取。我们先忽略从网络请求数据这一环节，假设数据已经保存在 DB 里，那我们要做的事就是，ViewController 从 DB 取数据，再传给 view 渲染：

这是最简单的情况，随着程序变复杂，多个 ViewController 都要向 DB 取数据，ViewController本身也会因为数据变化重新去 DB 取数据，会有两个问题：

• 数据每次有变动，ViewController 都要重新去DB读取，做 IO 操作。
• 多个 ViewController 之间可能会共用数据，例如同一份数据，本来在 Controller1 已经从 DB 取出来了，在 Controller2 要使用得重新去 DB 读取，浪费 IO。

对这里做优化，自然会想到在 DB 和 VC 层之间再加一层 cache，把从 DB 读取出来的数据 cache 在内存里，下次来取同样的数据就不需要再去磁盘读取 DB 了。

几乎所有的数据库框架都做了这个事情，包括微信读书开源的 GYDataCenter，CoreData，Realm 等。但这样做会导致一个问题，就是数据的线程安全问题。

按上面的设计，Cache层会有一个集合，持有从DB读取的数据。

除了 VC 层，其他层也会从cache取数据，例如网络层。上层拿到的数据都是对 cache 层这里数据的引用：

可能还会在网络层子线程，或其他一些用于预加载的子线程使用到，如果某个时候一条子线程对这个 Book1 对象的属性进行修改，同时主线程在读这个对象的属性，就会 crash，因为一般我们为了性能会把对象属性设为nonatomic，是非线程安全的，多线程读写时会有问题：

//Network
WRBook *book = [WRCache bookWithId:@“10000”];
book.fav = YES;   //子线程在写
[book save];

//VC1
WRBook *book = [WRCache bookWithId:@“10000”];
self.view.title = book.title;   //主线程在读

可以通过这个测试看到 crash 场景：

@interface TestMultiThread : NSObject
@property (nonatomic) NSArray *arr;
@end

@implementation TestMultiThread
@end

TestMultiThread *obj = [[TestMultiThread alloc] init];
for (int i = 0; i < 1000; i ++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        NSLog(@"%@", obj.arr);
    });
}
for (int i = 0; i < 1000; i ++) {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        obj.arr = [NSArray arrayWithObject:@“b"];
    });
}

解决方案

对这种情况，一般有三种解决方案：

1. 加锁

既然这个对象的属性是非线程安全的，那加锁让它变成线程安全就行了。可以给每个对象自定义一个锁，也可以直接用 OC 里支持的属性指示符 atomic：

@property (atomic) NSArray *arr;

这样就不用担心多线程同时读写的问题了。但在APP里大规模使用锁很可能会导致出现各种不可预测的问题，锁竞争，优先级反转，死锁等，会让整个APP复杂性增大，问题难以排查，并不是一个好的解决方案。

2. 分线程cache

另一种方案是一条线程创建一个 cache，每条线程只对这条线程对应的 cache 进行读写，这样就没有线程安全问题了。CoreData 和 Realm 都是这种做法，但这个方案有两个缺点：

• a.使用者需要知道当前代码在哪条线程执行。
• b.多条线程里的 cache 数据需要同步。

CoreData 在不同线程要创建自己的 NSManagedObjectContext，这个 context 里维护了自己的 cache，如果某条子线程没有创建 NSManagedObjectContext，要读取数据就需要通过 performBlockAndWait:等接口跑到其他线程去读取。如果多个 context 需要同步 cache 数据，就要调用它的 merge 方法，或者通过 parent-children context 层级结构去做。这导致它多线程使用起来很麻烦，API 友好度极低。

Realm 做得好一点，会在线程 runloop 开始执行时自动去同步数据，但如果线程没有 runloop 就需要手动去调 Realm.refresh()同步。使用者还是需要明确知道代码在哪条线程执行，避免在多线程之间传递对象。

3.数据不可变

我们的问题是多线程同时读写导致，那如果只读不写，是不是就没有问题了？数据不可变指的就是一个数据对象生成后，对象里的属性值不会再发生改变，不允许像上述例子那样 book.fav = YES直接设置，若一个对象属性值变了，那就新建一个对象，直接整个替换掉这个旧的对象：

//WRCache
@implementation WRCache
+(void) updateBookWithId:(NSString *)bookId params:(NSDictionary *)params
{
    [WRDBCenter updateBookWithId:@“10000” params:{@“fav”: @(YES)}]; //更新DB数据
    WRBook *book = [WRDBCenter readBookWithId:bookId]; //重新从DB读取，新对象
    [self.cache setObject:book forKey:bookId];  //整个替换cache里的对象
}
@end

self.book = [WRCache bookWithId:@“10000”];
// book.fav = YES;   //不这样写
[WRCache updateBookWithId:@“10000” params:{@“fav”: @(YES)}]; //在cache里整个更新
self.book = [WRCache bookWithId:@“10000”];   //重新读取对象

这样就不会再有线程安全问题，一旦属性有修改，就整个数据重新从DB读取，这些对象的属性都不会再有写操作，而多线程同时读是没问题的。

但这种方案有个缺陷，就是数据修改后，会在 cache 层整个替换掉这个对象，但这时上层扔持有着旧的对象，并不会自动把对象更新过来：

所以怎样让上层更新数据呢？有两种方式，push 和 pull。

a. push

push 的方式就是 cache 层把更新 push 给上层，cache对整个对象更新替换掉时，发送广播通知上层，这里发通知的粒度可以按需求斟酌，上层监听自己关心的通知，如果发现自己持有的对象更新了，就要更新自己的数据，但这里的更新数据也是件挺麻烦的事。

举个例子，读书有一个想法列表WRReviewController，存着一个数组 reviews，保存着想法 review 数据对象，数组里的每一个 review 会持有这个这个想法对应的一本书，也就是 review.book 持有一个 WRBook 数据对象。然后这时 cache 层通知这个 WRReviewController，某个 book 对象有属性变了，这时这个 WRReviewController 要怎样处理呢？有两个选择：

• 遍历 reviews 数组，再遍历每一个 review 里的 book 对象，如果更新的是这个 book 对象，就把这个 book 对象替换更新。
• 什么都不管，只要有数据更新的通知过来，所有数据都重新往 cache 层读一遍，重新组装数据，界面全部刷新。

第一种是精细化的做法，优点是不影响性能，缺点是蛋疼，工作量增多，还容易漏更新，需要清楚知道当前模块持有了哪些数据，有哪些需要更新。第二种是粗犷的做法，优点是省事省心，全部大刷一遍就行了，缺点是在一些复杂页面需要组装数据，会对性能造成较大影响。

b. pull

另一种 pull 的方式是指上层在特定时机自己去判断数据有没有更新。

首先所有数据对象都会有一个属性，暂时命名为 dirty，在 cache 层更新替换数据对象前，先把旧对象的 dirty 属性设为 YES，表示这个旧对象已经从 cache 里被抛弃了，属于脏数据，需要更新。然后上层在合适的时候自行去判断自己持有的对象的 dirty属性是否为 YES，若是则重新在 cache 里取最新数据。

实际上这样做发生了多线程读写 dirty属性，是有线程安全问题的，但因为 dirty属性读取不频繁，可以直接给这个属性的读写加锁，不会像对所有属性加锁那样引发各种问题，解决对这个 dirty属性读写的线程安全问题。

这里主要的问题是上层应该在什么时机去 pull 数据更新。可以在每次界面显示 -viewWillAppear或用户操作后去检查，例如用户点个赞，就可以触发一次检查，去更新赞的数据，在这两个地方做检查已经可以解决90%的问题，剩下的就是同个界面联动的问题，例如 iPad 邮件左右两栏两个 controller，右边详情点个收藏，左边列表收藏图标也要高亮，这种情况可以做特殊处理，也可以结合上面 push 的方式去做通知。

push 和 pull 两种是可以结合在一起用的，pull 的方式弥补了 push 后数据全部重新读取大刷导致的性能低下问题，push 弥补了 pull 更新时机的问题，实际使用中配合一些事先制定的规则或框架一起使用效果更佳。

总结

对于 APP 缓存数据线程安全问题，分线程 cache 和数据不可变是比较常见的解决方案，都有着不同的实现代价，分线程 cache 接口不友好，数据不可变需要配合单向数据流之类的规则或框架才会变得好用，可以按需选择合适的方案。

索引备份的几个关键问题

• 最简单的备份方式是关闭IndexWriter，然后逐一拷贝索引文件，但是如果索引比较大，那么这种备份操作会持续较长时间，而在备份期间，程序无法对索引文件进行修改，很多搜索程序是不能接受索引操作期间如此长时间停顿的
• 那么不关闭IndexWriter又如何呢？这样也不行，因为在拷贝索引期间，如果索引文件发生变化，会导致备份的索引文件损坏
• 另外一个问题就是如果原索引文件损坏的话，再备份它也毫无意义，所以一定要备份的是最后一次成功commit之后的索引文件
• 每次在备份之前，如果程序将要覆盖上一个备份，需要先删除备份中未出现在当前快照中的文件，因为这些文件已经不会被当前索引引用了；如果每次都更改备份路径的话，那么就直接拷贝即可

索引热备份

从Lucene 2.3版本开始，Lucene提供了一个热备策略，就是SnapshotDeletionPolicy，这样就能在不关闭IndexWriter的情况下，对程序最近一次索引修改提交操作时的文件引用进行备份，从而能建立一个连续的索引备份镜像。那么你也许会有疑问，在备份期间，索引出现变化怎么办呢？

这就是SnapshotDeletionPolicy的牛逼之处，在使用SnapshotDeletionPolicy.snapshot()获取快照之后，索引更新提交时刻的所有文件引用都不会被IndexWriter删除，只要IndexWriter并未关闭，即使IndexWriter在进行更新、优化操作等也不会删除这些文件。如果说索引拷贝过程耗时较长也不会出现问题，因为被拷贝的文件时索引快照，在快照的有效期，其引用的文件会一直存在于磁盘上。

所以在备份期间，索引会比通常情况下占用更大的磁盘空间，当索引备份完成后，可以调用SnapshotDeletionPolicy.release (IndexCommit commit) 释放指定的某次提交，以便让IndexWriter删除这些已被关闭或下次将要更新的文件。

需要注意的是，Lucene对索引文件的写入操作是一次性完成的。这意味着你可以简单通过文件名比对来完成对索引的增量备份备份，你不必查看每个文件的内容，也不必查看该文件上次被修改的时间戳，因为一旦程序从快照中完成文件写入和引用操作，这些文件就不会改变了。

segments.gen文件在每次程序提交索引更新时都会被重写，因此备份模块必须要经常备份该文件，但是在Lucene 6.0中注意segments.gen已经从Lucene索引文件格式中移除，所以无需单独考虑segments.gen的备份策略了。在备份期间，write.lock文件不用拷贝。

SnapshotDeletionPolicy类有两个使用限制

• 该类在同一时刻只保留一个可用的索引快照，当然你也可以解除该限制，方法是通过建立对应的删除策略来同时保留多个索引快照
• 当前快照不会保存到硬盘，这意味着你关闭旧的IndexWriter并打开一个新的IndexWriter，快照将会被删除，因此在备份结束前是不能关闭IndexWriter的，否则也会报org.apache.lucene.store.AlreadyClosedException: this IndexWriter is closed异常。不过该限制也是很容易解除的：你可以将当前快照存储到磁盘上，然后在打开新的IndexWriter时将该快照保护起来，这样就能在关闭旧的IndexWriter和打开新IndexWriter时继续进行备份操作

索引热备份解决方案

import org.apache.commons.io.FileUtils;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.*;
import org.apache.lucene.index.*;
import org.apache.lucene.search.TermQuery;
import org.apache.lucene.store.FSDirectory;

import java.io.File;
import java.io.IOException;
import java.nio.file.Paths;
import java.util.Collection;

import static org.apache.lucene.document.Field.Store.YES;

/**
 * 测试Lucene索引热备
 */
public class TestIndexBackupRecovery {

    public static void main(String[] args) throws IOException, InterruptedException {
        String f = "D:/index_test";
        String d = "D:/index_back";
        IndexWriterConfig indexWriterConfig = new IndexWriterConfig(new StandardAnalyzer());
        indexWriterConfig.setIndexDeletionPolicy(new SnapshotDeletionPolicy(new KeepOnlyLastCommitDeletionPolicy()));
        IndexWriter writer = new IndexWriter(FSDirectory.open(Paths.get(f)), indexWriterConfig);
        Document document = new Document();
        document.add(new StringField("ID", "111", YES));
        document.add(new IntPoint("age", 111));
        document.add(new StoredField("age", 111));
        writer.addDocument(document);
        writer.commit();
        document = new Document();
        document.add(new StringField("ID", "222", Field.Store.YES));
        document.add(new IntPoint("age", 333));
        document.add(new StoredField("age", 333));
        writer.addDocument(document);
        document.add(new StringField("ID", "333", Field.Store.YES));
        document.add(new IntPoint("age", 555));
        document.add(new StoredField("age", 555));
        for (int i = 0; i 1000; i++) {
            document = new Document();
            document.add(new StringField("ID", "333", YES));
            document.add(new IntPoint("age", 1000000 + i));
            document.add(new StoredField("age", 1000000 + i));
            document.add(new StringField("desc", "ABCDEFG" + i, YES));
            writer.addDocument(document);
        }
        writer.deleteDocuments(new TermQuery(new Term("ID", "333")));
        writer.commit();
        backupIndex(writer, f, d);
        writer.close();
    }

    public static void backupIndex(IndexWriter indexWriter, String indexDir, String
            backupIndexDir) throws IOException {
        IndexWriterConfig config = (IndexWriterConfig) indexWriter.getConfig();
        SnapshotDeletionPolicy snapshotDeletionPolicy = (SnapshotDeletionPolicy) config.getIndexDeletionPolicy();
        IndexCommit snapshot = snapshotDeletionPolicy.snapshot();
        //设置索引提交点，默认是null，会打开最后一次提交的索引点
        config.setIndexCommit(snapshot);
        Collection fileNames = snapshot.getFileNames();
        File[] dest = new File(backupIndexDir).listFiles();
        String sourceFileName;
        String destFileName;
        if (dest != null && dest.length > 0) {
            //先删除备份文件中的在此次快照中已经不存在的文件
            for (File file : dest) {
                boolean flag = true;
                //包括文件扩展名
                destFileName = file.getName();
                for (String fileName : fileNames) {
                    sourceFileName = fileName;
                    if (sourceFileName.equals(destFileName)) {
                        flag = false;
                        break;//跳出内层for循环
                    }
                }
                if (flag) {
                    file.delete();//删除
                }
            }
            //然后开始备份快照中新生成的文件
            for (String fileName : fileNames) {
                boolean flag = true;
                sourceFileName = fileName;
                for (File file : dest) {
                    destFileName = file.getName();
                    //备份中已经存在无需复制，因为Lucene索引是一次写入的，所以只要文件名相同不要要hash检查就可以认为它们的数据是一样的
                    if (destFileName.equals(sourceFileName)) {
                        flag = false;
                        break;
                    }
                }
                if (flag) {
                    File from = new File(indexDir + File.separator + sourceFileName);//源文件
                    File to = new File(backupIndexDir + File.separator + sourceFileName);//目的文件
                    FileUtils.copyFile(from, to);
                }
            }
        } else {
            //备份不存在，直接创建
            for (String fileName : fileNames) {
                File from = new File(indexDir + File.separator + fileName);//源文件
                File to = new File(backupIndexDir + File.separator + fileName);//目的文件
                FileUtils.copyFile(from, to);
            }
        }
        snapshotDeletionPolicy.release(snapshot);
        //删除已经不再被引用的索引提交记录
        indexWriter.deleteUnusedFiles();
    }
}

索引文件格式

首先索引里都存了些什么呢？一个索引包含一个documents的序列，一个document是一个fields的序列，一个field是一个有名的terms序列，一个term是一个比特序列。

根据 Summary of File Extensions的说明，目前Lucene 6.0中存在的索引格式如下

在Lucene索引结构中，既保存了正向信息，也保存了反向信息。
正向信息存储在：段(segments_N)->field(.fnm/.fdx/.fdt)->term(.tvx/.tvd/.tvf)
反向信息存储在：词典(.tim)->倒排表(.doc/.pos)

如果想要查看中文，可以参考 这里。

恢复索引

恢复索引步骤如下

• 关闭索引目录下的全部reader和writer，这样才能进行文件恢复。对于Windows系统来说，如果还有其它进程在使用这些文件，那么备份程序仍然不能覆盖这些文件
• 删除当前索引目录下的所有文件，如果删除过程出现“访问被拒绝”（Access is denied）错误，那么再次检查上一步是否已完成
• 从备份目录中拷贝文件至索引目录。程序需要保证该拷贝操作不会碰到任何错误，如磁盘空间已满等，因为这些错误会损坏索引文件
• 对于损坏索引，可以使用CheckIndex（org.apache.lucene.index）进行检查并修复

通常Lucene能够很好地避免大多数常见错误，如果程序遇到磁盘空间已满或者OutOfMemoryException异常，那么它只会丢失内存缓冲中的文档，已经编入索引的文档将会完好保存下来，并且索引也会保持原样。这个结果对于以下情况同样适用：如出现JVM崩溃，或者程序碰到无法控制的异常，或者程序进程被终止，或者操作系统崩溃，或者计算机突然断电等。

/**
 * @param source 索引源
 * @param dest 索引目标
 * @param indexWriterConfig 配置相关
 */public static void recoveryIndex(String source, String dest, IndexWriterConfig indexWriterConfig) {
    IndexWriter indexWriter = null;
 try {
        indexWriter = new IndexWriter(FSDirectory.open(Paths.get(dest)), indexWriterConfig);
  } catch (IOException e) {
        log.error("", e);
  } finally {
        //说明IndexWriter正常打开了，无需恢复
  if (indexWriter != null && indexWriter.isOpen()) {
            try {
                indexWriter.close();
  } catch (IOException e) {
                log.error("", e);
  }
        } else {
            //说明IndexWriter已经无法打开，使用备份恢复索引
 //此处简单操作，先清空损坏的索引文件目录，如果索引特别大，可以比对每个文件，不必全部删除  try {
                FileUtils.deleteDirectory(new File(dest));
  FileUtils.copyDirectory(new File(source), new File(dest));
  } catch (IOException e) {
                log.error("", e);
  //使用备份恢复出错，那么就使用最后一招修复索引
  log.info("Check index {} now!", dest);
 try {
                    IndexUtils.checkIndex(dest);
  } catch (IOException | InterruptedException e1) {
                    log.error("Check index error!", e1);
  }
            }
        }
    }
}

修复索引

当其它所有方法都无法解决索引损坏问题时，你的最后一个选项就是使用CheckIndex工具了。该工具除了能汇报索引细节状况以外，还能完成修复索引的工作。该工具会强制删除索引中出现问题的段，需要注意的是，该操作还会全部删除这些段包含的文档，该工具的使用目标应主要着眼于能够在紧急状况下让搜索程序再次运行起来，一旦我们进行了索引备份，并且备份完好，应优先使用恢复索引，而不是修复索引。

/**
 * CheckIndex会检查索引中的每个字节，所以当索引比较大时，此操作会比较耗时
 *
 * @throws IOException
 * @throws InterruptedException
 */
public void checkIndex(String indexFilePath) throws IOException, InterruptedException {
    CheckIndex checkIndex = new CheckIndex(FSDirectory.open(Paths.get(indexFilePath)));
    checkIndex.setInfoStream(System.out);
    CheckIndex.Status status = checkIndex.checkIndex();
    if (status.clean) {
        System.out.println("Check Index successfully！");
    } else {
        //产生索引中的某个文件之后再次测试
        System.out.println("Starting repair index files...");
        //该方法会向索引中写入一个新的segments文件，但是并不会删除不被引用的文件，除非当你再次打开IndexWriter才会移除不被引用的文件
        //该方法会移除所有存在错误段中的Document索引文件
        checkIndex.exorciseIndex(status);
        checkIndex.close();
        //测试修复完毕之后索引是否能够打开
        IndexWriter indexWriter = new IndexWriter(FSDirectory.open(Paths.get(indexFilePath)), new IndexWriterConfig(new
                StandardAnalyzer()));
        System.out.println(indexWriter.isOpen());
        indexWriter.close();
    }
}

如果索引完好，输出如下信息：

Segments file=segments_2 numSegments=2 version=6.0.0 id=2jlug2dgsc4tmgkf5rck1xgm4
1 of 2: name=_0 maxDoc=1
version=6.0.0
id=2jlug2dgsc4tmgkf5rck1xgm1
codec=Lucene60
compound=true
numFiles=3
size (MB)=0.002
diagnostics = {java.runtime.version=1.8.0_45-b15, java.vendor=Oracle Corporation, java.version=1.8.0_45, java.vm.version=25.45-b02, lucene.version=6.0.0, os=Windows 7, os.arch=amd64, os.version=6.1, source=flush, timestamp=1464159740092}
no deletions
test: open reader………OK [took 0.051 sec]
test: check integrity…..OK [took 0.000 sec]
test: check live docs…..OK [took 0.000 sec]
test: field infos………OK [2 fields] [took 0.000 sec]
test: field norms………OK [0 fields] [took 0.000 sec]
test: terms, freq, prox…OK [1 terms; 1 terms/docs pairs; 0 tokens] [took 0.007 sec]
test: stored fields…….OK [2 total field count; avg 2.0 fields per doc] [took 0.008 sec]
test: term vectors……..OK [0 total term vector count; avg 0.0 term/freq vector fields per doc] [took 0.000 sec]
test: docvalues………..OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET] [took 0.000 sec]
test: points…………..OK [1 fields, 1 points] [took 0.001 sec]
2 of 2: name=_1 maxDoc=1001
version=6.0.0
id=2jlug2dgsc4tmgkf5rck1xgm3
codec=Lucene60
compound=true
numFiles=4
size (MB)=0.023
diagnostics = {java.runtime.version=1.8.0_45-b15, java.vendor=Oracle Corporation, java.version=1.8.0_45, java.vm.version=25.45-b02, lucene.version=6.0.0, os=Windows 7, os.arch=amd64, os.version=6.1, source=flush, timestamp=1464159740329}
has deletions [delGen=1]
test: open reader………OK [took 0.003 sec]
test: check integrity…..OK [took 0.000 sec]
test: check live docs…..OK [1000 deleted docs] [took 0.000 sec]
test: field infos………OK [3 fields] [took 0.000 sec]
test: field norms………OK [0 fields] [took 0.000 sec]
test: terms, freq, prox…OK [1 terms; 1 terms/docs pairs; 0 tokens] [took 0.008 sec]
test: stored fields…….OK [2 total field count; avg 2.0 fields per doc] [took 0.012 sec]
test: term vectors……..OK [0 total term vector count; avg 0.0 term/freq vector fields per doc] [took 0.000 sec]
test: docvalues………..OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET] [took 0.000 sec]
test: points…………..OK [1 fields, 1001 points] [took 0.001 sec]
No problems were detected with this index.
Took 0.159 sec total.
Check Index successfully！

在破坏索引之后（删除了一个cfe文件），再次运行输出

Segments file=segments_2 numSegments=2 version=6.0.0 id=2jlug2dgsc4tmgkf5rck1xgm4
1 of 2: name=_0 maxDoc=1
version=6.0.0
id=2jlug2dgsc4tmgkf5rck1xgm1
codec=Lucene60
compound=true
numFiles=3
FAILED
WARNING: exorciseIndex() would remove reference to this segment; full exception:
java.nio.file.NoSuchFileException: D:index_test_0.cfe
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:79)
…
…
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
2 of 2: name=_1 maxDoc=1001
version=6.0.0
id=2jlug2dgsc4tmgkf5rck1xgm3
codec=Lucene60
compound=true
numFiles=4
size (MB)=0.023
diagnostics = {java.runtime.version=1.8.0_45-b15, java.vendor=Oracle Corporation, java.version=1.8.0_45, java.vm.version=25.45-b02, lucene.version=6.0.0, os=Windows 7, os.arch=amd64, os.version=6.1, source=flush, timestamp=1464159740329}
has deletions [delGen=1]
test: open reader………OK [took 0.059 sec]
test: check integrity…..OK [took 0.000 sec]
test: check live docs…..OK [1000 deleted docs] [took 0.001 sec]
test: field infos………OK [3 fields] [took 0.000 sec]
test: field norms………OK [0 fields] [took 0.000 sec]
test: terms, freq, prox…OK [1 terms; 1 terms/docs pairs; 0 tokens] [took 0.013 sec]
test: stored fields…….OK [2 total field count; avg 2.0 fields per doc] [took 0.016 sec]
test: term vectors……..OK [0 total term vector count; avg 0.0 term/freq vector fields per doc] [took 0.000 sec]
test: docvalues………..OK [0 docvalues fields; 0 BINARY; 0 NUMERIC; 0 SORTED; 0 SORTED_NUMERIC; 0 SORTED_SET] [took 0.000 sec]
test: points…………..OK [1 fields, 1001 points] [took 0.002 sec]
WARNING: 1 broken segments (containing 1 documents) detected
Took 0.165 sec total.
Starting repair index files…
true

Lucene 6.0 实战：索引热备份及恢复，首发于 文章 - 伯乐在线。