按照会议安排，早晨有两个讲座，下午有四个讲座，每个讲座1个小时左右。第一个出场的是腾讯的安全中心总监杨勇，整个演讲很轻松，首先是对腾讯的整体产品结构和背景作了一下阐述，然后就从安全中心这个整体来讲述安全对于腾讯的意义，如何实施以及一些流程的制定。没有过多的牵涉安全问题的细节，着重是讲述了安全中心面临的四个方面的问题，以及通过什么手段去解决。这其实和他本身所处的工作职责来说相符合，如果仅仅只是来讲某一个安全技术应用，那么就有些太过狭隘了。不过在提问的时候一个问题的回答让我还是留有一些印象的，主持人收集到一个问题：“腾迅安全中心的建设初期遇到的最迫切需要解决的问题是什么？”，他回答道：“其实腾讯安全中心从建设初期到现在一直面临各种迫切的问题，只是随着时间的不同而不同的演变，最早的协议安全到客户端安全到奥运期间的信息安全都是一个发展的阶段”（因为没有ppt以及记录，因此描述的可能不太准确）。但是这个思想任何技术行业都是一样的，时代不同关注不同，需要解决的问题也是在发展的。

   第二个议题是Discuz的剑心带来的“web应用程序中的字符集攻击”，这个演讲就相对来说比较注重专业细节方面的阐述。作为互联网应用开发者，使用Java的人第一堂课就是中文乱码，很多人只看到如何去配置或者写一点转换语句就可以解决，但是对于编码方式就不求甚解，ISO-8859-1,GB2312,UTF-8,UTF-16区别是什么，为什么会引起乱码。其实了解了编码的原理就很能够解释如何会产生乱码，同时产生乱码的时候也可以根据乱码的情况了解可能是因为什么编码转化造成的（阿里巴巴的宝宝写了一篇很详细的文章说了这个问题，进入公司以后我也是看了那片文章才系统地对编码方式做了完整的了解，以前都是碎片）。不过今天听了这个演讲，到让我知道了原来编码方式也被人用来攻击。其实基本的思想主要就是一点：由于信息转发中对于不同编码解析的方式不同或者是过滤不同，导致出现一些漏洞。通俗的比喻就是刺杀秦始皇的图穷匕见，侍卫就好比第一层把关的信息转发者认为着幅图没有威胁，但是真的按照刺客的处理方式那么就是一个最好的攻击性工具。记得我在和同事探讨REST对于Http协议的使用时说最重要的就是REST不再使用Http协议作为传输承载协议而是作为业务协议，那么解析业务的时候究竟是分析协议中指定的编码方式还是内容中的编码方式，结果会大不一样，同时作为安全人员的角度来看，这也会存在一种安全隐患。所以其实任何一种错误都可以被利用作为攻击的手段。

    下午的议题一共有四个，虽然时间比较长一直连续讲到6点多，但是就像主持人讲的，每一个人都“坚持”下来了，呵呵，当然坚持并不是因为不好听，而是做在那儿听比写代码要累很多，当然讲课的同学们也是十分辛苦的。下午第一个演讲的是team509的创始人吴石，讲的主题是“部分软件安全的思考”，内容专业化很强，对很多比较底层的安全问题（操作系统等）作了一些介绍，当然对于我这个门外汉只能听懂个大概意思，不过还是有所了解那些名词的意思到底是什么。第二个是微软的大牛蛙同学，也是安全领域专家讲述了一下微软的SDL(Security Development Lifecycle)，望名生意，安全实施的流程化。第三个演讲是两位同学做的，也是我下午听得比较有感触地，先是网名余弦（钟晨鸣）北京知道创宇信息技术公司的安全研究员，讲的是CSRF蠕虫技术，从一个黑客的角度来阐述CSRF的原理以及危害性。这部分比较技术化一些，但是由于和我关注的Web安全也比较相关一些，所以听起来也不是比较迷糊。虽然听着他讲CSRF，但是其实我脑子里面已经在考虑关于Open API的一些安全问题。其实在阿里软件承载淘宝的API过程中，对于客户端的安全问题就一直都在谈，但是对于SIP来说总是鞭长莫及，因为服务集成平台只会保障ISV和ISP之间的信息交互的真实性，但是用户是否由于ISV的技术问题导致信息伪造提交，那么就不得而知，但是最后表现出来的结果就是ISP的Open API计划为ISP带来了更多的安全隐患，也就是说原来淘宝一家漏洞，以后可能会是千千万万家ISV的漏洞，其实这也是上面几个演讲提到的合作风险问题，第三方的技术能力不得而知，同时产生的风险也会很难控制。其实从这里也多多少少看出来为什么FaceBook，myspace，最早对于用户安全隐私数据的开放不仅仅是开放了数据API，同时也会有整一套上层框架支持，其实也是出于开发者能力不足引起隐私数据被恶意修改而作的防护措施。那么现在Open 用户的数据特别是以后涉及到金额的api如何保证isv不欺诈，isv不被欺骗，这可能是后续需要更加重视的问题。同时，在听了CSRF的攻击中谈到的对于资源定位猜测以及操作的时候，让我对REST的风格又打了一个冷颤，REST对于资源的规划和定位十分容易，但是这也为这类攻击提供了便利，同时对于资源操作依赖于Http协议，也会让资源的安全性打了折扣，这需要对Open API开发人员做更多的安全工作指导，或者提供安全框架来防范Open API可能会产生的安全漏洞。紧接着后面的演讲是北京知道创宇信息技术公司的创始人赵伟，应该是业界比较资深的专家了，本来的议题是“恶意网站检测”，不过他还是讲了他这些年来的一些经历以及安全领域的黑色产业链的问题。平时这方面关注的不多，不过今天这一番交流，让我对安全领域的发展以及现况有所了解，甚至有时候就觉得现在上网就算装了一大堆东西还是感觉在“裸奔”。最后一个议题是51.com的郑歆炜讲的“运维安全经验谈”，总结了运维所面对的问题以及解决方案，协调，沟通，总结，知识库，其实这些对于开发人员来说何尝不是呢。最后小黑作了一个简短的总结，同时预报了明天他会做一次附加的构建安全Web架构的讲座，期待明天半天的研讨会和附加讲座。

    好久没有踏踏实实地坐着好好听课了，这次一天半的学习对于自己来说也算是一次新知识的扫盲，同时也为自己后续的工作可能存在的问题或者可以借鉴的知识作一个铺垫。

Blog: http://blog.csdn.net/cenwenchu79/

问题

         小丹同学在旺旺上问我是否可以用Memcached实现简易消息中间件类似的功能。觉得这个需求很奇怪，就问了一下具体的应用场景，然后小丹就上来和我具体的谈了究竟需求是什么。其实小丹的应用场景是这样的：客户需要分析一些业务数据，但是业务数据又是很庞大的，在原有系统每天晚上都有一次日分析，将业务数据分析并且归档，但是如果要产生即时分析的效果，用原有系统无法实现，因为当天的数据内容没有被分析，同时如果即时的去分析并且累加到历史分析数据上，性能也不能满足需求，因此考虑通过消息机制来实现异步分析，至于异步处理的时间容忍度，可以通过配置来实现，同时希望异步分析是可线性扩展的，支持集群，提高效率。为什么不直接使用中间件呢？高并发的稳定性，维护的成本，性能要求，使用成本，这些直接就排出了直接去使用中间件的想法。

起始方案的讨论

         在回到小丹最初提到是否可以通过Memcached来实现类似于简易消息中间件的问题上来。首先是否将消息队列作为一个对象保存在Memcached中，这种做法明显不支持高并发的情况，因为Cache本身的get,put无法保证事务。在Memcached中只有计数器是支持高并发的操作，因此考虑是否使用计数器并且按照一定规则来生成key，通过对计数器的增减来让不同消费者获取到不同的消息，这种机制最大的问题在于：1.轮询的压力不小（小丹希望是订阅者模式，Push过去而不是Pull）。2.计数器增减不论怎么做都实现的是栈而不是队列。那么是否使用我扩展的Memcached的KeySet，这点我自己就反对了，这个功能效率很低，而且对于Memcached本身在高并发下操作是否有影响还不得而知。问题越绕越走向死胡同了。

方案的转变

         转换思路，重新分析小丹的需求，究竟哪几点是他真实需要的：1.通过消息方式解耦Web应用和业务分析处理。2.消息必须较为及时的传递到业务分析模块。3.业务分析模块需要支持集群方式线性扩展性能。实现这些需求真的需要简单的消息中间件或者集中式存储么？看看下图的结构：

回过头来看看Memcached的使用情况，突然发现其实事情可以简单来说，我记得写过一些说明来解释为什么我说Memcached是集中式缓存而不是分布式缓存，其实是客户端的分发算法让很多人觉得好像分布了数据和可无限扩展。其实这种技术结合Hadoop 的HDFS的部分设计思路，可以给出一个比较好的解决方案。看看下图的结构设计：

上图去掉了消息中间件的角色，增加了Asyn Processor Manager的角色，但是此角色也可以去掉，更为简化的实现需求，增加Asyn Processor Manager的功能仅仅是为了提供动态增减Asyn Processor的功能。具体说一下流程：

1．              Web应用启动时，读取本地配置获取Asyn Processor列表载入内存，同时根据Asyn Processor Manager的配置去发起请求获取Asyn Processor最新的可用列表（如果无法获取，则以本地的为准）。

2．              Web应用根据本地实现的分发算法（最简单就是采用key hash），来选择Asyn Processor，发送请求处理的消息。

3．              如果Asyn Processor Manager不存在，Web应用也可以实现定时发起query status请求来确认Asyn Processor的存活状态，并且更新，保证消息的正常发送。如果Asyn Processor Manager存在，那么确认Asyn Processor状态是否存活可以由Asyn Processor Manager来做（Push或者Pull），而Web应用则可以使用对Asyn Processor Manager的定时查询来获得最新的Asyn Processor列表。

4．              Asyn Processor Manager可以提供增加和删除Asyn Processor的接口，这样就可以支持Asyn Processor的增加和删除，但也正因为Asyn Processor Manager的单点易于注册和管理Asyn Processor，也增加了单点的风险，因此每一台Web应用需要对Asyn Processor Manager不可用作好本地化配置的后备策略。

5．              使用Http协议作为消息传输协议，这样避免SA去维护端口的麻烦，同时也能够充分利用REST的方式来完成业务逻辑（Options方法可以用于心跳，Put、Delete可以用于Processor的增减（设置Http Head认证方式即可解决安全问题），Get方式获取信息（xml,json等等格式可以很容易处理））。

上面的方案可以看出，如果去掉Asyn Processor Manager，其实方案很简化，就是每一个客户端有一层类似于Memcached客户端的分发机制，同时比Memcached免去了对于连接池维护的复杂性，仅仅只需要维护状态标示即可。

最后还嘱咐小丹对于Asyn Processor的设计需要合理化，这部分需要支持消息接受和处理的并行处理，提高Asyn Processor的处理能力，同时通过分页批量处理消息的方式减少对于DB的压力（当然需要根据具体的时效性设置消息页的大小以及消息页Flush的时间）。

后话

    1.通过REST服务请求完成状态迁移，同时合理利用OPTIONS来查看资源操作权限。

    2.合理利用Http Heads来返回资源URI，以及通过ErrorCode来确定操作结果，并且作后处理。

    3.通过返回内容指定后续流程资源定位以及操作来实现流程化。

    4.通过Put报头的两种版本比较标示来防止并发修改。（其实也可以优化来做查询缓存的工作）

    5.使用Atom协议来发布和管理资源（Atom是最适合REST风格服务的数据源格式定义）

    6.URI模版的使用建议，慎用，如果确实能够有把握抽象资源定位。

    7.Auth可以通过轻量级Http Head中的Authentication或者WS-*的方式来实现。（也可以通过https实现）

    总的来说，其实整个案例分析下来以后，可以发现如果要使得服务流程化，那么前提就是数据交互格式统一（XML，Atom），然后利用Http协议作为服务协议而非承载协议，利用已有的操作约定，报文头部标示和返回的错误码来完成资源状态迁移的工作，同时通过在返回内容中嵌入流程化内容，使得整个流程可以贯穿。（这里还是简单的流程串联，其实如果在流程规则协议中增加复杂的逻辑定义，则可以实现更为强大的Web workflow）。

    但对于Open API或者类似的REST流程化业务来说，安全其实还是最大的挑战，特别是在对资源的访问控制权限上。当然可以类似于WS-Security提出一套较为安全成熟的方案，但是性能和使用简易性则会大打折扣，也失去了REST本身的优势。

   邮件如下：

   你好：
<socketpool name="pool0" failover="true" initConn="5" minConn="5"
  maxConn="250" maintSleep="5000" nagle="false" socketTO="3000"
  aliveCheck="true" >
  <servers>10.0.0.16:11111</servers>
  <weights>10</weights>
 </socketpool>
能解释下maintSleep这个意思么？我看有的资料说吧它设置为0性能更好，能给些建议么？谢谢！！我们现在的PV大约每天500万。

    这个参数是对此连接池维护线程的检查间隔时间的配置，如果配置小于等于0，则将不会有后台线程维护此连接池，参数单位为毫秒，下面解释一下维护连接池的含义，其实就和其他的资源池一样，资源池的目的就是为了解决资源的申请和释放的开销增加系统压力的问题，将资源通过池的方式回收重用，有利于系统性能的提高。memcached cache client 其实是通过socket来和服务端进行通信，建立socket连接也是比较消耗时间的工作，因此配置了池的初始连接数（initConn），最小连接数（minConn），最大连接数（maxConn）。这三者关系如下图，维护他们之间状态转移的就是后台线程。

    后台进程维护资源池的作用就是将有限资源回收，例如数据库连接，如果一台oracle只有500个连接数可以支持，那么如果一个应用都占用了50个闲置，那对于其他需要资源的应用来说无疑是一种浪费。但如果配置了资源管理，但由于应用属于忙时和闲时交替比较频繁的情况，那么如果时间配置的不是很合适，就会达不到原来资源池的作用，资源反复回收和申请。所以对于这个参数的配置，个人觉得一定要配，配置的值需要注意，初始化和最小的值可以是自己预估平时平均并发处理的均值，最大的连接数当然依赖于资源的总数，而维护时间间隔则最好是能够根据闲时和忙时的情况来考虑配置，这样既不会浪费资源，同时也不会使资源池时效。

    顺带说一句，如果对于数据丢失要求不是很苛刻，然后网络情况也不错的时候，可以将aliveCheck设置为false，因为如果是true，在每一次发送任何数据操作之前都会去做心跳检查，这个未来也会考虑去优化。

    那么回顾一下我对赵进的感受，那么就能够体现出如果要成为一个架构师，或者是一个首席架构师应该具有的能力，首先就是微笑，其次就是倾听，再则就是引导，最后就是坚持。微笑可以化解敌意，倾听可以找出问题，引导可以商讨解决方案，坚持可以达到目标。当然双赢之类的就不说了。其实说到能力，在我看来技术方面的能力是可以培养的，要成为技术上的能人，需要专注，坚持和勤奋，但是要成为一个架构师那么最重要的还是胸怀和眼界，能够容纳别人才会让别人接受你，这些说起来都很容易，但是做起来却是很难，因为这和个性也有关系，改变自己的个性需要勇气和时间。

    我现在MSN的名字叫做海纳百川，时时告诉自己有容乃大，整天为了一些细枝末节的重复劳动而沾沾自喜，只会变成井底之蛙，要做就要做别人没有做或者做不到的，多了解一些，多学习一些，站在不到巨人的肩膀上也站到石头上，看得更高才会走得更远。

    一年过去之际，勉励自己改变自己。

    有架构师的能力，却没有宽广的胸怀，那么永远只会停留在一个代码编写者阶段。

    有宽广的胸怀，却只有程序员的能力，那么只要努力就会成为架构师甚至首席架构师。
    （打个广告^_^，年底关于Open API的文章由于要发表在杂志上，因此无法在这里贴了，不过到了一月份应该就可以贴了，这篇关于Open API的文章是自己沉淀自己大半年工作的一份总结，也希望能够分享给大家）

因此这阵子除了优化Memcache客户端和SIP框架逻辑以外其他依赖部分以外，对于内存泄露的压力测试也开始实实在在的做起来。经过这次问题的定位和解决以后，大致觉得对于一个大用户量应用要放心的话，那么需要做这么几步。

1.       在GC输出的环境下，大压力下做多天的测试。（可以在 JAVA_OPTS增加-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError）

2.       检查GC输出日志来判断是否有内存泄露。（这部分后面有详细的实例说明）

3.       如果出现内存泄露问题，则使用jprofiler等工具来排查内存泄露点（之所以不一开始使用，因为jprofiler等工具对于压力测试有影响，使得大压力无法上去，也使问题不那么容易暴露）

4.       解决问题，并在重复2步骤。

这里对SIP在jdk1.5和jdk1.6下做压力测试的GC 日志来做一个实际的分析对比，通过对比来大致描述一下如何根据输出情况能够了解应用是否存在内存泄露问题。（这里的内存泄露问题就是在以前blog写过的jdk的concurrent包内LinkedBlockingQueue的poll方法存在比较严重的内存泄露，调用频率越高，内存泄露的越厉害）

两次压力测试都差不多都是两天，测试方案如下：

开始50个并发，每个并发每次请求完毕后休息0.1秒，10分钟后增长50个并发，按此规律增长到500并发。

旧版本SIP是在JDK1.5环境下完成的压力测试，

新版本SIP的JDK版本是1.6，

压力机和以前一样，是10.2.226.40，DELL1950，8CPU，8G内存。

压力机模拟发出对一个需要签名的API不断的调用请求。

看看两个Log的具体内容（内容很多截取部分做分析）

先说一下日志输出的结构：(1.6和1.5略微有一些不同，只是1.6对于时间统计更加细致)

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]

<collector>GC收集器的名称

<starting occupancy1> 新生代在GC前占用的内存

<ending occupancy1> 新生代在GC后占用的内存

<pause time1> 新生代局部收集时jvm暂停处理的时间

<starting occupancy3> JVM Heap 在GC前占用的内存

<ending occupancy3> JVM Heap 在GC后占用的内存

<pause time3> GC过程中jvm暂停处理的总时间

Jdk1.5 log：

启动时GC输出：

[GC [DefNew: 209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K), 0.0204050 secs]

[GC [DefNew: 214209K->4381K(235968K), 0.0139200 secs] 251139K->41312K(498112K), 0.0141190 secs]

一句输出：

新生代回收前209792K，回收后4417K，回收数量205375K，Heap总量回收前246722K回收后41347K，回收总量205375K。这就表示100%的收回，没有任何新生代的对象被提升到中生代或者永久区（名字说的不一定准确，只是表达意思）。

第二句输出：

按照分析也就只是有1K内容被提升到中生代。

运行一段时间后：

[GC [DefNew: 210686K->979K(235968K), 0.0257140 secs] 278070K->68379K(498244K), 0.0261820 secs]

[GC [DefNew: 210771K->1129K(235968K), 0.0275160 secs] 278171K->68544K(498244K), 0.0280050 secs]

第一句输出：

         新生代回收前210686K，回收后979K，回收数量209707K，Heap总量回收前278070K回收后68379K，回收总量209691K。这就表示有16k没有被回收。

第二句输出：

         新生代回收前210771K，回收后1129K，回收数量209642K，Heap总量回收前278171K回收后68544K，回收总量209627K。这就表示有15k没有被回收。

比较一下启动时与现在的新生代占用内存情况和Heap使用情况发现Heap的使用增长很明显，新生代没有增长，而Heap使用总量增长了27M，这就表明可能存在内存泄露，虽然每一次泄露的字节数很少，但是频率很高，大部分泄露的对象都被升级到了中生代或者持久代。

又一段时间后：

[GC [DefNew: 211554K->1913K(235968K), 0.0461130 secs] 350102K->140481K(648160K), 0.0469790 secs]

[GC [DefNew: 211707K->2327K(235968K), 0.0546170 secs] 350275K->140921K(648160K), 0.0555070 secs]

第一句输出：

         新生代回收前211554K，回收后1913K，回收数量209641K，Heap总量回收前350102K回收后140481K，回收总量209621K。这就表示有20k没有被回收。

         分析到这里就可以看出每一次泄露的内存只有10几K，但是在大压力长时间的测试下，内存泄露还是很明显的，此时Heap已经增长到了140M，较启动时已经增长了100M。同时GC占用的时间越来越长。

后续的现象：

         后续观察日志会发现，Full GC的频率越来越高，收集所花费时间也是越来越长。（Full GC定期会执行，同时局部回收不能满足分配需求的情况下也会执行）。

[Full GC [Tenured: 786431K->786431K(786432K), 3.4882390 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)], 3.4887920 secs]

java.lang.OutOfMemoryError: Java heap space

Dumping heap to java_pid7720.hprof ...

         出现这个语句表示内存真的被消耗完了。

Jdk1.6 log：

启动时GC的输出：

[GC [PSYoungGen: 221697K->31960K(229376K)] 225788K->36051K(491520K), 0.0521830 secs] [Times: user=0.26 sys=0.05, real=0.05 secs]

[GC [PSYoungGen: 228568K->32752K(229376K)] 232659K->37036K(491520K), 0.0408620 secs] [Times: user=0.21 sys=0.02, real=0.04 secs]

第一句输出：

         新生代回收前221697K，回收后31960K，回收数量189737K，Heap总量回收前225788K回收后36051K，回收总量189737K。100%被回收。

运行一段时间后输出：

[GC [PSYoungGen: 258944K->2536K(259328K)] 853863K->598135K(997888K), 0.0471620 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]

[GC [PSYoungGen: 259048K->2624K(259328K)] 854647K->598907K(997888K), 0.0462980 secs] [Times: user=0.16 sys=0.02, real=0.04 secs]

第一句输出：

         新生代回收前258944K，回收后2536K，回收数量256408K，Heap总量回收前853863K回收后598135K，回收总量255728K。680K没有被回收，但这并不意味着就会产生内存泄露。同时可以看出GC回收时间并没有增加。

在运行一段时间后输出：

[GC [PSYoungGen: 258904K->2488K(259264K)] 969663K->713923K(1045696K), 0.0485140 secs] [Times: user=0.16 sys=0.01, real=0.04 secs]

[GC [PSYoungGen: 258872K->2448K(259328K)] 970307K->714563K(1045760K), 0.0473770 secs] [Times: user=0.16 sys=0.01, real=0.05 secs]

第一句输出：

         新生代回收前258904K，回收后2488K，回收数量256416K，Heap总量回收前969663K回收后713923K，回收总量255740K。676K没有被回收，同时总的Heap也有所增加。

         此时看起来好像和1.5的状况一样。但是查看了一下Full GC的执行还是400-500次GC执行一次，因此继续观察。

运行一天多以后输出：

[GC [PSYoungGen: 257016K->3304K(257984K)] 1019358K->766310K(1044416K), 0.0567120 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

[GC [PSYoungGen: 257128K->2920K(258112K)] 1020134K->766622K(1044544K), 0.0549570 secs] [Times: user=0.19 sys=0.00, real=0.05 secs]

可以发现Heap增长趋缓。

运行两天以后输出：

[GC [PSYoungGen: 256936K->3584K(257792K)] 859561K->606969K(1044224K), 0.0565910 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

[GC [PSYoungGen: 256960K->3368K(257728K)] 860345K->607445K(1044160K), 0.0553780 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]

发现Heap反而减少了，此时可以对内存泄露问题作初步排除了。（其实在jdk1.6环境下用jprofiler来观察，对于concurrent那个内存泄露点的跟踪发现，内存的确还是会不断增长的，不过在一段时间后还是有回收，因此也就可以部分解释前面出现的情况）

总结：

         对于GC输出的观察需要分两个维度来看。一个是纵向比较，也就是一次回收对于内存变化的观察。一个是横向比较，对于长时间内存分配占用情况的比较，这部分比较需要较长时间的观察，不能仅仅凭短时间的几个抽样比较，因为对于抽样来说，Full GC前后的区别，运行时长的区别，资源瞬时占用的区别都会影响判断。同时要结合Full GC发生的时间周期，每一次GC收集所耗费的时间作为辅助判断标准。

         顺便说一下，Heap的 YoungGen,OldGen,PermGen的设置也是需要注意的，并不是越大越好，越大执行收集的时间越久，但是可能执行Full GC的频率会比较低，因此需要权衡。这些仔细的去了解一下GC的基础设计思想会更有帮助，不过一般用默认的也不错。还有就是可以配置一些特殊的GC，并行，同步等等，充分利用多CPU的资源。

         对于GC的优化可以通过现在很多图形工具来做，也可以类似于我这样采用最原始的分析方式，好处就是任何时间任何地点只要知道原理就可以分析无需借助外部工具。原始的总是最好的^_^。

         写了那么些，其实思路比较乱，我想从随笔里面也看得出来，但是还是想记录一下自己的一些思考，起码以后回过头来可以看到自己成长的过程。

    这里把我另外一部分的内容贴出来。

    Memcached是一种集中式Cache，支持分布式横向扩展。这里需要有点说明，很多开发者觉得Memcached是一种分布式Cache，但是其实Memcached服务端本身是单实例的，只是在客户端实现过程中可以根据存储的主键作分区存储，而这个区就是Memcached服务端的一个或者多个实例，如果将客户端也囊括到Memcached中，那么可以部分概念上说是集中式的。其实回顾一下集中式的构架，无非两种情况：1.节点均衡的网状（JBoss Tree Cache），利用JGroup的多播通信机制来同步数据。2.Master-Slaves模式（分布式文件系统），由Master来管理Slave，如何选择Slave，如何迁移数据，都是由Master来完成，但是Master本身也存在单点问题。

总结几个它的特点来理解一下它的优点和限制。

         Memory：内存存储，不言而喻，速度快，对于内存的要求高，不指出的话所缓存的内容非持久化。对于CPU要求很低，所以常常采用将Memcached服务端和一些CPU高消耗Memory低消耗应用部属在一起。（作为我们AEP正好有这样的环境，我们的接口服务器有多台，接口服务器对于CPU要求很高（由于WS-Security），但是对于Memory要求很低，因此可以用作Memcached的服务端部属机器）

         集中式Cache：避开了分布式Cache的传播问题，但是需要非单点保证其可靠性，这个就是后面集成中所作的cluster的工作，可以将多个Memcached作为一个虚拟的cluster，同时对于cluster的读写和普通的memcached的读写性能没有差别。

         分布式扩展：Memcached的很突出一个优点，就是采用了可分布式扩展的模式。可以将部属在一台机器上的多个Memcached服务端或者部署在多个机器上的Memcached服务端组成一个虚拟的服务端，对于调用者来说完全屏蔽和透明。提高的单机器的内存利用率，也提供了scale out的方式。

         Socket通信：传输内容的大小以及序列化的问题需要注意，虽然Memcached通常会被放置到内网作为Cache，Socket传输速率应该比较高（当前支持Tcp和udp两种模式，同时根据客户端的不同可以选择使用nio的同步或者异步调用方式），但是序列化成本和带宽成本还是需要注意。这里也提一下序列化，对于对象序列化的性能往往让大家头痛，但是如果对于同一类的Class对象序列化传输，第一次序列化时间比较长，后续就会优化，其实也就是说序列化最大的消耗不是对象序列化，而是类的序列化。如果穿过去的只是字符串，那么是最好的，省去了序列化的操作，因此在Memcached中保存的往往是较小的内容。

         特殊的内存分配机制：首先要说明的是Memcached支持最大的存储对象为1M。它的内存分配比较特殊，但是这样的分配方式其实也是对于性能考虑的，简单的分配机制可以更容易回收再分配，节省对于CPU的使用。这里用一个酒窖比喻来说明这种内存分配机制，首先在Memcached起来的时候可以通过参数设置使用的总共的Memory，这个就是建造一个酒窖，然后在有酒进入的时候，首先申请（通常是1M）的空间，用来建酒架，酒架根据这个酒瓶的大小分割酒架为多个小格子安放酒瓶，将同样大小范围内的酒瓶都放置在一类酒架上面。例如20cm半径的酒瓶放置在可以容纳20-25cm的酒架A上，30cm半径的酒瓶就放置在容纳25-30cm的酒架B上。回收机制也很简单，首先新酒入库，看看酒架是否有可以回收的地方，如果有直接使用，如果没有申请新的地方，如果申请不到，采用配置的过期策略。这个特点来看，如果要放的内容大小十分离散，同时大小比例相差梯度很明显，那么可能对于使用空间来说不好，可能在酒架A上就放了一瓶酒，但占用掉了一个酒架的位置。

         Cache机制简单：有时候很多开源的项目做的面面俱到，但是最后也就是因为过于注重一些非必要性的功能而拖累了性能，这里要提到的就是Memcached的简单性。首先它没有什么同步，消息分发，两阶段提交等等，它就是一个很简单的Cache，把东西放进去，然后可以取出来，如果发现所提供的Key没有命中，那么就很直白的告诉你，你这个key没有任何对应的东西在缓存里，去数据库或者其他地方取，当你在外部数据源取到的时候，可以直接将内容置入到Cache中，这样下次就可以命中了。这里会提到怎么去同步这些数据，两种方式，一种就是在你修改了以后立刻更新Cache内容，这样就会即时生效。另一种是说容许有失效时间，到了失效时间，自然就会将内容删除，此时再去去的时候就会命中不了，然后再次将内容置入Cache，用来更新内容。后者用在一些时时性要求不高，写入不频繁的情况。

         客户端的重要性：Memcached是用C写的一个服务端，客户端没有规定，反正是Socket传输，只要语言支持Socket通信，通过Command的简单协议就可以通信，但是客户端设计的合理十分重要，同时也给使用者提供了很大的空间去扩展和设计客户端来满足各种场景的需要，包括容错，权重，效率，特殊的功能性需求，嵌入框架等等。

         几个应用点：小对象的缓存（用户的token，权限信息，资源信息）。小的静态资源缓存。Sql结果的缓存（这部分用的好，性能提高相当大，同时由于Memcached自身提供scale out，那么对于db scale out的老大难问题无疑是一剂好药）。ESB消息缓存。