应用软件开发到IT集成测试，压力专项测试阶段，Demo演示阶段，突然发现性能不好甚至内存溢出，这都很常见，经验时面向客户时遇到了不要慌，咱们解决就是了，从哪方面考虑呢，开发时多多考虑，3s原则，3s应该要出数据等等。

不好的方向：从重构，架构问题

有的同事一上来就给你说重构，哪里哪里写得太烂.....这时候千万别着急从架构重构上考虑，已经到能演示，集成测试或压力测试阶段，说明业务没问题，现在弄出最优的架构在当前业务和交付时间面前，代价有点大，重构也不一定能解决问题，比如业务上要加载个很大很大的PDF到业务代码里，架构怎么搞都会在加载PDF那个点出现内存溢出，没找到根本原因盲目修改是比较浪费时间的，架构和系统都是在项目整个生命周期一点点优化，架构设计好了很难*翻推**重来，除非有时间有资金有人才，去重头再来这个项目

好的方向：业务代码是不是有多余循环，SQL是不是可以优化，找出业务流程中高内存点

• 有的for循环里包含了一个SQL查询，这个SQL查询的条件是不变的，或者要查询的表过大，可以把这个SQL提到循环外面处理，或者调用的别的共通类，这个类每次耗时长，想办法提到循环外，提前或推后执行
• SQL优化，SQL里是不是有 Left join，inner join，UNION ALL 操作符，Count(1)发现A表很大几百万条数据，就可以把A表的A.S1 = '1'提到A里，先做A表的子查询

Select * From A Left join B ON A.S1 = '1'

变为：

Select From (SELECT * FROM A WHERE A.S1 = '1') Left join B

• UNION ALL的情况可以考虑子查询提到with as里，先执行重复的子查询with as，再去做别的查询
• SQL里如果有查询比较慢的表，数据量比较大，可以把Where条件里的字段，新加个索引
• Debug日志里，看看每个方法进入开始到出来时间是多少，找出花费时间长的优化
• 当有大量的插入和更新时，把一条插入或更新的语句改为5000条数据一起插入或更新，试试，这时候可以考虑多线程，并发执行
• 当有并发要求是，比如1s内同时上线1000人，这样的请求，先考虑服务端开线程，比如加到128线程，同时去接客户端来的请求
• 当依赖于别的服务或别的软件提供信息，比如用户登录业务的前端服务A，依赖于存储有用户账号密码的后端服务B，可以加本地定时缓存，去存储一些固定的信息，每次客户端来请求A服务，就不用再去别的服务B里找，先在内存缓存里找，找不到在去别的服务（别的服务器上）找，减少链接时间成本
• 在查询前，比如SQL查表，A表有几百个字段，查询一次也很花时间，先用Select Count(1) From A Where A.S1=XXX，去看看满足条件的数据有多少条，如果0条，就可以不查了
• 开出IDE的内存监测，看看业务上某个点是否内存太大，比如发现运行到加载gif图片，或PDF，有的Gif图片超过正常要求，达到128帧，加到内存里反复*放播**就内存突然就溢出了，没必要这么大的gif，把gif改小，就把问题解决了，或者PDF有时候太大，加载不玩，那只能展示那一页就加载那一页，用转成图片的方式，等等优化，