beralee的世界

呃，最近太忙，都没怎么写blog…

公司访问不了国外网站，这才是最悲催的事情…

ppt准备的不是很充分，不过相关内容应该都点到了，重在实践

(更多…)

以前听 @bluedavy 讲过几次集合类一定要限制大小避免内存溢出，却没有引起足够的重视，没想到今天真的遇到了。

过程如下：下午在线下的稳定环境突然出现了内存溢出，java.lang.OutOfMemoryError: Java heap space 。先观察日志，主要业务逻辑并没有完全停止运行，即使commons-error日志里一堆的内存溢出，也并没有完全影响到主要的功能逻辑，所以可以大概确定是一些非核心服务导致的，再仔细观察commons-error，有不少ibatis执行时抛出的OOM，根据堆栈信息，又联想到之前做的一个模块：一个线程定时轮询数据库，根据时间标记，取出这段时间内需要处理的数据，使用完毕后删除掉。再去看这个功能模块的日志，果然，每几分钟轮询数据库时就打出一次OOM错误，再联想到bluedavy提到的集合类限制大小的问题，立刻明白原因很可能是定时捞取数据的时候，数据量过大，直接超出了堆内存最大值，所以导致内存溢出。查一下开发环境数据库，果然如此，定时捞取数据的sql执行一下会查出300W+的数据，添加到List，一次性加载到内存里，自然就溢出了。
(更多…)

写设计文档时总要在word里贴一份所谓的表结构设计的表格，一个一个整理太麻烦了，用groovy写个小程序生成一下，就当练手了。
下面的代码会生成一个xls文件，excel打开后再拷到word里选一下格式就变成表格，就基本可以使用了，也就是说我没有引入任何操作word文件的包，那样太麻烦了。
只支持mysql，其他数据库的话把里面的两个sql和数据库连接相应的改掉就可以了。
(更多…)

eclipse的设置模块设计的非常糟糕，没有一个专门的配色方案模块，各种配置参数只能整合在一个epf文件里，如果直接把其他人的配色方案导出再导入你的eclipse里经常会出一些问题，甚至导致ec无法启动。
(更多…)

设置一个合适服务端系统的线程数又是一件事半功倍的事情。

最佳线程数的东西我是最近才从淘宝的一份ppt上看到的，这里总结一下：

前面说了怎样合理的找到系统的瓶颈，解决系统的问题，这时候系统应该比较健康了，如果还想要进一步压榨系统的性能，就必须从一些参数下手，而调整参数实在是一件事半功倍的事情。

JVM参数调优总的来讲主要分两个方面：1.代大小的调优 2.垃圾回收机制的调优。主要的调优方向也是两个：减少full gc次数，减少每次gc所使用的时间。

(更多…)

通过jprofiler可以比较容易的分析出当前系统有没有内存泄漏的情况，如果没有内存泄漏，系统正常运行，cpu使用率还是比较高，在这个情况下，就需要找出使用CPU比较高的代码来进行专门的优化。

(更多…)

前面说到几种代码问题导致cpu的us使用过高的情况，其中最不容易查找原因的就是内存泄漏问题了，而且内存泄漏导致的后果可能直接是程序挂掉无法使用，轻微的内存泄漏又往往需要很久的时间才会重现，而内存泄漏导致heap内存接近最大值时频繁gc又会导致cpu占用高。下面是我的一些分析内存泄漏的经验。
(更多…)

有了压测，我们就可以让系统高速运转起来了，这时候，系统的问题就会被放大，首先可以从CPU的使用上分析出一些东西。

cpu load:

cpu的load是由很多因素构成，其中最主要的因素是CPU自己维护的队列的长度，例如在1分钟里，CPU的队列里维持的任务量始终为1，这个时候CPU load就基本等于1，这个值越大，就意味着CPU越忙，系统的负载就越大，一般这个值不超过3是比较好的状态。

cpu 利用率：

cpu 利用率是CPU时间在用户进程，内核处理，空闲时间，io时间等的百分比，一般java应用比较关注的就是用户进程和内核处理两块的百分比，这两块在系统负载情况下执行的百分比在65%-70%和30%-35%比较好。
(更多…)

前面说了压力测试，对于开发人员来说要掌握loadrunner并不是特别的必要，自己写测试代码又不好统计分析，这时候可以用一些更简单更适合我们的测试工具，比如apache ab。

ab并不是一个单独的工具，他是apache服务器里的一个小工具，在apache安装目录的bin目录下面，就可以找到他了。它是一个命令行工具，使用起来非常容易，格式是 ab [options] [http://]hostname[:port]/path 其中options有不少选项，具体可以看一下官方文档 http://httpd.apache.org/docs/2.0/programs/ab.html
(更多…)