最近优化了一项系统的性能，总结心得如下，希望对大家有用。先说大致的业务以及优化的成果（这不是炫耀，但是此处应该有掌声。哎，自娱自乐是种病，都怪我放弃了治疗）。
同时处理N个用户，每个用户需要根据不同的条件进行相应的操作，这里的操作可能是更新其他表，可能是插入其他表得根据用户的状态进行判断。当然了这里的N不是全部的用户，是根据联合查询得来的一个List。需要说明的是这个查询语句已经被前人优化的非常好了，所以查询的优化不是考虑范围之内的。
说到性能优化，准确的说是底层性能优化说到底无非就是JPQL改SQL或者无索引加索引这些简单的操作。只要找到了原因在哪，修改代码绝对不是问题，就像那首歌里唱的“有一位老人在中国的南海边画了一个圈”画完圈之后要做的事情是容易的，难的是在哪里画这个圈。同样画圈的故事还有下面这个：
美国福特公司一台大型电机发生故障,所有工程师束手无策,最后请来一名德国工程师。他绕着电机走了几圈,听了听声音,然后用粉笔在电机上画了一个圈,对所有人说,“打开,把这里的线圈减少16圈”。结果,故障排除了。事后,德国工程师索要3万美元报酬。福特公司提出疑问,为什么画一个圈居然索价这么高？德国工程师回答,画一个圈1美元,知道在哪里画圈29999美元。
如何发现性能瓶颈
第一：测试数据尽可能真实
第二：测试数据尽可能真实
第三：参考上面两点
为什么这么说呢，这次优化的时候因为数据量是一千五百万，考虑到时间问题自己当时就想偷个懒，造几百万数据得了，结果运行了几遍没发现什么问题。至于偷懒的原因我是这么安慰自己的“就算用存储过程对数据库进行插入操作，几百万条数据也是需要不少时间的，而且数据基本上用完还得再造（好吧我承认我的水平洼，请大牛们赐教如何快速造数据啊）”种种原因吧，两天之后还是一筹莫展，于是就像普通的侦探小说中描述的那样，在截止日期之前“案件”一度陷入僵局，最后被逼无奈才开始使用生产数据进行测试。
不要忽略任何线索
起初第一次用生产数据测试的时候只是关注后台日志中的错误，压根就没有把什么warning放在眼里更别说什么info了（事实证明info的确没什么大用）后来查看日志的时候发现了warning的日志，原来连接池满了。Glassfish默认是32，改成320之后运行稳定，并且总时间从五十多分钟提升到了六分钟。其实我知道这个数字是需要一步一步调整的，指导调整到一个最佳的数值，既不浪费内存又能保证系统效率。性能优化说难也难说简单也简单，简单到比之前就多画了一个圈，难在解决问题之前你不知道问题到底出在哪里。
(借我借我一双慧眼吧$_$)
托尔斯泰说“幸福的家庭是相似的，不幸的家庭各有各的不同”对于系统也是一样的，“高性能的系统是相似的，低性能的系统各有各的瓶颈”。这次的调优仅仅是系统优化技巧的冰山一角，但是调优的思路是通用的，找出瓶颈----解决瓶颈，所以说找问题的能力比解决问题的能力更难能可贵。