java系统性能优化（六）- 解决CPU使用高的代码
通过jprofiler可以比较容易的分析出当前系统有没有内存泄漏的情况，如果没有内存泄漏，系统正常运行，cpu使用率还是比较高，在这个情况下，就需要找出使用CPU比较高的代码来进行专门的优化。
java系统性能优化（五）- 分析内存泄漏
前面说到几种代码问题导致cpu的us使用过高的情况，其中最不容易查找原因的就是内存泄漏问题了，而且内存泄漏导致的后果可能直接是程序挂掉无法使用，轻微的内存泄漏又往往需要很久的时间才会重现，而内存泄漏导致heap内存接近最大值时频繁gc又会导致cpu占用高。下面是我的一些分析内存泄漏的经验。
(更多…)
java系统性能优化（四）- 通过CPU状态分析系统瓶颈
有了压测，我们就可以让系统高速运转起来了，这时候，系统的问题就会被放大，首先可以从CPU的使用上分析出一些东西。
cpu load:
cpu的load是由很多因素构成，其中最主要的因素是CPU自己维护的队列的长度，例如在1分钟里，CPU的队列里维持的任务量始终为1，这个时候CPU load就基本等于1，这个值越大，就意味着CPU越忙，系统的负载就越大，一般这个值不超过3是比较好的状态。
cpu 利用率：
cpu 利用率是CPU时间在用户进程，内核处理，空闲时间，io时间等的百分比，一般java应用比较关注的就是用户进程和内核处理两块的百分比，这两块在系统负载情况下执行的百分比在65%-70%和30%-35%比较好。
(更多…)
java系统性能优化（三）-apache ab的使用
前面说了压力测试，对于开发人员来说要掌握loadrunner并不是特别的必要，自己写测试代码又不好统计分析，这时候可以用一些更简单更适合我们的测试工具，比如apache ab。
ab并不是一个单独的工具，他是apache服务器里的一个小工具，在apache安装目录的bin目录下面，就可以找到他了。它是一个命令行工具，使用起来非常容易，格式是 ab [options] [http://]hostname[:port]/path 其中options有不少选项，具体可以看一下官方文档 http://httpd.apache.org/docs/2.0/programs/ab.html
(更多…)
java系统性能优化（二）-压力测试
前面说了，要不要做一次彻底的软件优化还得分析一下，那我们来看看我们的系统现在是个什么情况吧。
首先，要对你的系统非常熟悉，至少是主要的功能模块，如果代码是自己写的，那就最好了，否则，面对一个陌生的系统，就很难下手了。
java系统性能优化（一）-优化的意义
下周要分享这个话题，希望能比在以前公司做的更好一点，在这里先准备一下。
首先，性能优化意味着什么？
看个漫画先：
做性能优化之前必须要先掂量一下：
a.现在的系统处理能力不能满足需求
b.现在的系统处理能力有比较大的上升空间
c.花时间改进软件提升的性能比增加硬件划的来
如果你觉得上面三项都满足的话，那么就开始干吧！
当然，这几项不是一下子就能得到答案的，必须要经过分析和评估才能下结论，但可以肯定的一点就是，一次成功的系统性能优化，意味着省钱。
nexus one获得root的一些记录
为了获得最新版的google map，想给nexus one获取root权限，这样可以伪装成美国运营商的手机去market更新，直接google了几篇文章开始搞了，没想到调研不足，获取root后手机启动没有信号，相当于变砖了。
本来要睡觉来着，被迫只能开始折腾了。
重新google，发现那些获得root权限的文章都是针对android2.1的，而我已经升级到最新的2.2.1了，用老的方式root是没有用的，只好找了最新的rooted的FRF91的包给刷上，刷完后启动，手机有了信号，松了口气，谁知wifi打不开，只显示“错误”两个字，看来还是杯具，不少人都遇到这种问题，但是android2.2.1版本还没见到有人说解决，后来看到有篇文章说可以刷官方的包把root还原，又下了出厂时最的2.1版本rom，fastboot刷之，wipi之，但是unlock状态是没办法还原的，开机画面还是有个锁被打开的图标。
重启后终于正常了，但是版本回到了古老的2.1，连多点触摸都没有，这时更新系统却说当前是最新系统，输入#*#*checkin*#*#也不给更新，不知道是原因是什么，如果是root的原因那么等官方OTA也永远等不到，最后还是手动刷官方包了，官方包命名都是XXX FROM XXX的，需要一个一个刷，android2.1 to android2.1update to android2.2 刷了两次总算回到2.2了，目前一切正常，2.2.1看看官方能不能OTA推过来，不行的话可能手机就失去自动更新系统的功能了，以后2.3来了就只能手动刷了。
我觉得nexus one还是不要root的好，root后就无法享受官方的最新更新，更新后要么root失效，要么无法更新，要么出各种问题，还是老老实实享受官方版本的稳定和速度吧。
nexus two神马的不知道会不会还会向全球开发者赠送，但愿还能有一份。
八个改善Java遗留系统的技巧
你没看错，就是这个题目：即使是Java系统也会变成“遗留”系统。每当我们想起遗留系统时，我们就会想起那些存储着大量文件数据并只能用COBOL访问的嘎吱嘎吱作响的大型主机。但事实是，Java已经是一门具有15年历史的开发语言，用Java写就的成千上万的系统已经成功运行了十年甚至更久。
前段时间马云的公开信
各位阿里人，
几天前，有朋友问我今生最相信什么，我说:”我相信相信!”。
最近我发现很多阿里人非常郁闷和难过，大批网络报道指责淘宝网调整搜索结果，甚至还惹起了某些卖家来淘宝网门口抗议示威…看到那么多同事很委屈，甚至流下了眼泪，也发现不少年轻的淘宝人在不断自问:”我们到底做错了什么，为了鼓励大家在淘宝上创业，坚持七年不向会员强制收取开店费和交易费，坚持扶持发展创业者和中小卖家,七年多的日日夜夜奋斗，结果换回来的是各种各样的指责，我们值得这样吗?我们选择的路对吗?我们是否应该放弃自己促进新商业文明的使命而回到仅仅是一家普普通通的赚钱公司……”
本来应该早点和大家做一个交流，谈谈我的看法，但最近一系列的问题…呵呵，我觉得阿里人必须有这么一个经历，阿里人需要有时间接受各种各样的挑战，”男人的胸怀是由冤枉撑大的”，我觉得阿里人需要有在纷乱的外部环境中学会用自己的脑袋思考问题和判断问题的能力。选择今天和大家交流是因为快到阿里十一周年庆了，到了我们重温去年这时候提出的:阿里巴巴要促进开放、透明、分享，责任的新商业文明，为全世界一千万家中小企业提供一个生存和发展的平台，为全世界解决一个亿的就业机会，为全球十亿人提供一个消费的平台……的时候。
从提出这么一个伟大的使命和目标起，我就觉得我们从此以后会走上一条艰难的发展之路，我们会碰见各种不同类型的阻力和困难。今天的麻烦还仅仅是个开头，我们会碰上越来越多的挫折…坚持做正确的事，坚持自己的理想和使命是一定要付出巨大代价的，在任何时代都一样。尤其在今天的中国的商业环境里，促进开放，透明，分享，责任的商业文明一定会破坏大批既得利益群体，我们要抗争的不仅仅是这些既得利益群体还有是上世纪的商业习惯..
前段时间，淘宝人作出基于捍卫消费者用户的利益，同时支持提供优质服务和诚信卖家的搜索调整决策,我认为是正确的!我深以为豪的是我们的同事能放弃自己今天的利益而去追求创建更加有利于用户可持续健康发展的公平方法!!!但遗憾的是大家的好意被曲解,支持诚信卖家被说成是放弃中小卖家,保护消费者利益的措施被指责成获取自己的商业利益.:( 因为我们毕竟不是生活在真空的世界里, 互联网是一个大世界，淘宝网也是个大社会……我们也同样在电子商务的世界里面对欺诈，假货横行等一切社会现象。今天的社会上出现了很大的消极，浮燥的情绪，很多人怀疑一切，打击一切，否定一切,总把自己对世界的片面认识强加给别人,……还有不少媒体过度的使用”惩恶”的手端，而不是” 扶正祛邪”，使得人们不相信还有人会做好事，还会有人会为理想和原则而工作….
坚持还是放弃? 放弃，从此以后我们就会成为一家平庸的公司，因为利益而活着，我们可能会在一段时间里会很轻松，会很赚钱…而坚持理想，我们也许会每天碰上今天的状况，我们要和各种势力做斗争，包括巨大的黑色产业链中的恶势力。但坚持也会让我们生存和工作的有意义，坚持也会让我们能在21世纪里成为一家真正对人类社会有贡献的公司，让我们今天付出的一切努力有独特的回报…
我想阿里人应该，必须也只有选择坚持原则、坚持理想、坚持使命的发展之路!!
对那些相信新商业文明和支持阿里巴巴成为理想主义公司的社会各界朋友们说, 我们的上帝只有一个，就是用户。我们会更加在平时的工作中完善自己的服务和功能，我们会加强倾听客户，我们会坚持以保护消费者权益, 维护卖家利益为原则。我们坚信在未来的商业社会里，将没有大企业和小企业的区别，没有外资和内资的区别，没有国企和民企的区别，我们觉得只有诚信不诚信的区别，只有开放和不开放的区别，只有承担责任和不承担责任的区别…我们将全力支持那些诚信、开放和承担责任的企业。我们为我们自己工作中的不当,不成熟,不完善而道歉，我们保证将不断的努力，不断的创新…我们不追求最具影响力，我们追求对人类，对社会，对家庭和对自己最有贡献力!
对那些辛苦创业者们，我想说今天是创业最好的时候。一切梦想的成功一定和眼泪和汗水有关，和坚持诚信努力有关! 商业就不该害怕竞争,害怕竞争就不该做商业。我们害怕的是不透明的竞争，不诚信的竞争，不公平的竞争!怨天尤人的人永远会输给拥抱变化、改变自己的人!
对于我们的阿里人，我想说的是，我们坚持了十一年的理想很不容易，但我们还将坚持91年的理想! 我们从第一天起就坚持赚钱不是我们的目的，而仅仅是我们的结果。我们这家由80、90后组成的公司，我们必须有别于昨天的企业。我们感恩自己的公司诞生于这个社会，我们会因为今天的社会环境而成长，我们更应该为这个商业社会的完善而存在!这也是我们每天认真工作的意义所在。阿里人, 我们自己的未来一定是由我们今天乐观积极的态度和努力决定的!
对那些躲在背后的网络黑色产业链和希望我们放弃原则的人们，我想说，我们从来不会因为利益而改变自己，我们更不会因为压力而放弃自己的原则! 我们将会面对任何挑战，…我们宁可关掉自己的公司也不会放弃自己的原则！ 今后我们希望全社会来监督我们的商务政策调整，假如我们的调整政策违背了开放、透明、分享、责任的原则，我们一定会认真倾听而修改。否则我们将会犹如捍卫生命那样捍卫我们的使命！
请那些想通过闹事和传播谎言获益的人注意，你们的举动不仅仅在伤害两万多名优秀努力年轻人的理想，你们也在破坏和打击数千万以网络为生存的小企业以及几亿消费者的利益。阿里人感谢真诚的建议和批评，但是别有用心的意见，无理取闹和片面的东西，我们不会接受，即使你们付诸于游行示威甚至更加过激的手段，试图通过这些手段让我们让步屈服，数亿消费者不会答应的。我们坚信并会积极的参与到社会积极进步的力量中去…
阿里人，为理想而战吧!
此时此刻，非我莫属!
马云
2010.9.5
优化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策略应该是比较适合的，以后有时间再试试看吧。