记得有个伟人说过一句话，不要对你的程序做过早的优化，这句话个人执行的不错，没事的时候谁去针对代码做一些优化，尤其是在没有突出问题的时候。那啥时候需要做性能优化呢，有三个时间，一个是自己调试或者测试代码实在太慢的时候，一个是压力测试暴露出来的时候，一个就是线上暴露的响应慢的时候。
首先第一个时间，举一个实际的例子，我们通常会对数据库表中的数据做一些统计分析，并把分析的结果写入另一张表里中。由于多表关联，数据量巨大，代码逻辑中还嵌套了很多的for，导致一个统计跑了很久很久。这个时候是自己都看不下去了，必须优化提高性能。曾经从以下几个方便入手过：数据库索引，表关联查询简化语句，跟dba学习修改成高效的sql，代码逻辑中for循环里面尽量避免有数据库方便的操作（这点曾经犯过不少，因为毕竟这么些符合人类思维，先要做出正确的结果，但是缺忽略了性能，近期从一开始就不会这么干了），批量操作（主要是数据库批量插入，那比for循环里一条条的insert效率高多了）等等。
第二个压力测试阶段，主要是测并发了，针对接口做的测试，主要体现在并发数量太少了。做过的优化有JVM性能优化，Nginx提高性能的几个配置调整，代码数据结构的优化，缓存的使用，应用配置等。JVM的调整本身做的比较少，一般就是内存和线程配置，还没涉及到GC的配置修改。Nginx的配置就是work_connections，长连接，负载配置等，当然有时候需要调整Linux内核的几个参数或者Windows注册表中的几个参数。代码数据结构类似于第一阶段的措施。缓存这块就是数据从数据库查询搬到redis缓存中去读取。应用配置方面就是tomcat的线程数，连接数等。
第三阶段就是线上爆雷被客户怼的时候，有人会问有问题还会到线上吗？唉，怎么说的，就是线上出的问题多，哪怕是一样的配置。很多东西是测试不出来的，可能一样逻辑的代码线上有可能出bugs。这个阶段采取的措施就是重复第一第二阶段中采取的措施反复试错，最后让系统稳定，让客户不在提除了业务（非互联网行业）以外的问题。
总结一下，早期应用的部署都是在物理机上，自己手装服务器的操作系统，甚至还是32位的，可以说各种问题都会出来，不光性能问题，有的时候程序跑着跑着系统文件缺失了，而且还缺少运维监管，反正问题不少。现在大多数系统都是64位的，而且都是云上的，有很完善的系统监管保障，各项性能指标一目了然，偶然出的问题都是代码问题，配置问题也少了。
