java系统性能优化（二）-压力测试
前面说了，要不要做一次彻底的软件优化还得分析一下，那我们来看看我们的系统现在是个什么情况吧。
首先，要对你的系统非常熟悉，至少是主要的功能模块，如果代码是自己写的，那就最好了，否则，面对一个陌生的系统，就很难下手了。
java系统性能优化（一）-优化的意义
下周要分享这个话题，希望能比在以前公司做的更好一点，在这里先准备一下。
首先，性能优化意味着什么？
看个漫画先：
做性能优化之前必须要先掂量一下：
a.现在的系统处理能力不能满足需求
b.现在的系统处理能力有比较大的上升空间
c.花时间改进软件提升的性能比增加硬件划的来
如果你觉得上面三项都满足的话，那么就开始干吧！
当然，这几项不是一下子就能得到答案的，必须要经过分析和评估才能下结论，但可以肯定的一点就是，一次成功的系统性能优化，意味着省钱。
八个改善Java遗留系统的技巧
你没看错，就是这个题目：即使是Java系统也会变成“遗留”系统。每当我们想起遗留系统时，我们就会想起那些存储着大量文件数据并只能用COBOL访问的嘎吱嘎吱作响的大型主机。但事实是，Java已经是一门具有15年历史的开发语言，用Java写就的成千上万的系统已经成功运行了十年甚至更久。
优化JVM参数提高eclipse运行速度
受此文启发： http://www.longtask.com/blog/?p=592
性能优化从身边做起。
首先建立评估体系，将workspace里所有的项目close掉，关闭eclipse。优化的用例就是启动eclipse，open一个项目，eclipse会自动build这个项目，保证没有感觉到明显的卡，也就是没有full GC。
开始：
eclipse.ini里加入打印gc情况的参数：
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-verbose:gc
-Xloggc:gc.log
这样eclipse在运行过程中会记录gc日志，显示详细的gc情况，并打印在gc.log中，通过分析这个日志寻找eclipse的性能瓶颈和优化方式。
我最初的参数只是在原版基础上调了堆大小
-Xms512m
-Xmx512m
将堆初始化和最大值设为一样，消除堆大小根据当前堆使用情况而变化带来的影响。
启动eclipse，发现gc.log里打出了很多full gc的日志
4.226: [Full GC 4.226: [Tenured: 18470K->19304K(30544K), 0.1159544 secs] 25154K->19304K(44368K), [Perm : 24574K->24554K(24576K)], 0.1160431 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]
在启动的6秒多时间里共出现了8次full gc，所以启动慢，觉得启动时候挺卡的。从日志里可以看出来 FullGC主要是在回收tenured区和Perm区，其中Perm一直都是快满的状态，Perm : 24574K->24554K(24576K)，Perm大小在不断调整，所以需要固定Perm区的大小，保证够用，eclipse.ini里加入
-XX:PermSize=64m
-XX:MaxPermSize=64m
再启动：发现没有full gc了只有数量比较多的minor gc，挑启动开始到启动完成的第一条和最后一条日志
0.209: [GC 0.209: [DefNew: 4416K->511K(4928K), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
….
6.383: [GC 6.383: [DefNew: 18880K->1985K(21184K), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]
这6秒中GC日志打了69次， 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了，可以看出young区是由小到大在不断调整大小，所以不断GC，因此设一个初始值吧，据说设置heap的1/4比较好，那就是128M，所以eclipse.ini加入
-Xmn128m
再重启，发现GC日志就四条了，eclipse启动自然快了
1.292: [GC 1.292: [DefNew: 104960K->10984K(118016K), 0.0334165 secs] 104960K->10984K(511232K), 0.0334603 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
2.182: [GC 2.182: [DefNew: 115944K->1852K(118016K), 0.0221714 secs] 115944K->11466K(511232K), 0.0222142 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]
3.987: [GC 3.987: [DefNew: 106779K->12531K(118016K), 0.0378228 secs] 116393K->22145K(511232K), 0.0378692 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
5.377: [GC 5.377: [DefNew: 117491K->9403K(118016K), 0.0513728 secs] 127105K->31364K(511232K), 0.0514133 secs]
但是，启动后open我的多个项目，这些项目互相依赖，eclipse自动build，感觉有点小卡，发现日志里多了4次full GC，所以就卡了…
67.320: [Full GC (System) 67.320: [Tenured: 88847K->68809K(393216K), 0.2121213 secs] 117385K->68809K(511232K), [Perm : 41915K->41915K(65536K)], 0.2121747 secs] [Times: user=0.20 sys=0.00, real=0.20 secs]
103.759: [Full GC (System) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]
这个时候Tenured区和Perm都还没到很接近最大值，但是为什么还有full GC呢，开始以为是JVM悲观认为Tenured区剩余空间不足以应对下一次minor GC 所以进行了full GC调整Tenured空间，索性直接增加了堆最大值到-Xmx728m（工作电脑的内存是3.5G），但重启后full gc还是有4次，而且有几次minor GC用的时间超过了0.1秒，这是因为增加了堆大小，导致GC用时也增加了，不能接受。所以还是改回-Xmx512m。
再仔细观察日志，发现Full GC (System) 字样，这个意思是eclipse里调用了System.gc()手动触发了系统GC，好吧，哥已经给你分配足够空间了，你就省省吧，在eclipse.ini里加入：
-XX:+DisableExplicitGC
这样就差不多了，整个过程没有出现full gc，再编码2个小时，中间只出现了一次full gc，在open build某50W行+的代码的时候，eclipse还是卡了…
最后又稍微调了一下各代的大小，得到目前的参数：
-Xms512m
-Xmx512m
-XX:PermSize=96m
-XX:MaxPermSize=96m
-Xmn168m
-XX:+DisableExplicitGC
另外没有去调GC策略，主要是觉得eclipse是客户端程序，默认的client单线程的GC策略应该是比较适合的，以后有时间再试试看吧。
eclipse的手势插件
用惯了chrome和firefox的手势插件功能，写代码的时候难免也会想要划几下，这就找到一个eclipse下的手势插件Fast Fox，支持eclipse3.4,左划后退，右划前进，上划关闭，下划选择，还是挺好用的，基本满足需求了。
更新地址是：http://www.oixx.se/fastfox/
另有其他的优秀插件
利用好工具，也是提高工作效率的不错的途径。
Sun JDK OOM问题排查（转）
转自bluedavy的博客：
Java的自动内存管理机制给开发人员带来了很多的便利，在设计、开发时可以完全不用考虑要分配多少内存，要记得回收内存等，但同时也带来了各种各样的问题，其中最典型的问题就是OOM，大部分Java开发人员估计都看到过java.lang.OutOfMemoryError这样的错误信息，在这篇文章中，就来介绍下Sun JDK中有哪几种OOM、OOM示例、造成OOM的原因的查找、解决以及Sun JDK代码中处理OOM的方式。 (更多…)
Vim命令的壁纸
现在的工作需要用到无界面的Linux，需要操作Vim，之前没有使用过，找到一个写满命令的壁纸，以便查找。
使用Google日历做工作日报
在上一家公司工作的时候，每天上班第一件事是写当天的工作日志，也就是制定工作计划，最初是每人都记录在一个电子日记的软件里面，然后发给直接上司和部门管理者，后来大家觉得那软件不好用，又很麻烦，就都改成只发邮件的形式，一开始邮件要带一个excel附件，用来规范日志的格式，后来大家觉得附件也怪麻烦的，就干脆直接写邮件正文。但是有的人写的详细，细化到每小时做的事，有的人写的简单，例如“改bug”。再后来有尝试搭建wordpress博客，让大家写在博客里，还有说要做成系统的，总之形式丰富多彩，一直没有很好的解决这个问题。 (更多…)
在厦门最后一次的技术分享
这是离开厦门前做的最后一次技术分享，虽然起初是被上面要求的工作，拖延了离职的时间，但我还是挺认真的准备了，算是对毕业后这第一份工作的一个小小的总结。
技术分享分两部分，一个是并发编程，一个是性能优化。说实话这两块我还远远算不上精通，主要是拿出一些经验来分享。
主要都是以实例为主，所以PPT上没有什么东西。并发这块主要包括线程安全和JUC包的并发设施的实例。内容参考了网络上的相关PPT。性能优化这块主要是遇到性能问题的查找问题的方法，以请求二期调优为例 http://www.beralee.com/archives/18 介绍了jprofile等工具查找内存泄漏，性能瓶颈的方法。
五种开源协议的比较(BSD,Apache,GPL,LGPL,MIT) – 整理
我觉得这个挺重要的，算是喜欢玩开源的基础知识吧。是转贴，原文不知道是在哪里了。
现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种（http://www.opensource.org/licenses/alphabetical）。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。
这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。 (更多…)