• Top1
循环sql（批量查询，批量新增，批量修改）、redis（合理数据类型和使用管道）、dubbo、http请求等操作。
解析：以循环dubbo调用为例，dubbo调用需要走局域网络发送数据，唤起目标服务的dubbo线程，占用数据库连接，最后接收数据这一漫长的过程。如果循环多次调用，会有巨大的性能开销。根据前面优化的经验，如：调用主数据请求100条商品信息优化成批量后，性能将会有90%以上的提升。如果你代码中没有top1案例的情况，那么恭喜你，你避免了60%以上的性能问题。
• Top2
sql查询时，控制返回字段和返回记录数
解析：目前erp很多数据库表有超过60个的字段，如果一个sql 全字段查询几百甚至上千条记录。这会占用大量的io 和 内存，甚至触发GC，导致cpu过高导致宕机。之前有过 全字段查询两千多条记录而宕机的记录。当然也有没有判断查询条件，导致查询全表数据而宕机的记录。还有哥们查询一个几千记录的list,只是为了判断一下size是否为零。 [○･｀Д´･ ○]
• Top3
合理使用线程池，尽量用消息队列代替
解析：首先要说的是要用好多线程很难。使用多线程就是为了充分利用cpu的资源，提高程序执行效率。就是说，整个任务的执行时长会变短，但当执行时的cpu使用率会增高，如果核心线程数配置过大，甚至会导致cpu耗尽宕机。又或者执行多线程任务时，cpu维持在70~80%，这个时候又来了一个请求，并且存在top1,top2所描述的问题，那也能把这台机器怼挂。二代ERP是一个分布式系统，应该要充分利用集群的优势。如果有一个大任务要执行，尽量用mq拆分成小任务执行，避免单机cpu过高。
这里聊聊为什么要用mq代替多线程。前面库存模块有个记账业务，使用的是多线程执行。业务量比较大，每天有几十万的记账业务需要执行。库存把记账任务通过dubbo调用分发到不同中台的线程池异步执行。但是会存在分布不均，有的机器上分配了几万笔记账，有的则只有几百。当分配多的时候，任务需要放入堵塞队列等待执行，堵塞队列过大也会占用内存。当机器重启时，正在执行和在堵塞队列的任务还会丢失。而mq分配基本达到了绝对均匀，而有高可用保证消息不丢失的机制。如：某些业务想要用多线程，请联系我和组长讨论。
注：1.分发任务的线程池核心数，不能大于中台机器数x2; 2.执行任务线程池线程池核心数不能大于2；3.mq消费线程数，日消息大于10w的业务设置为2，其他都设置为1；
• Top4
慢sql
解析：数据库使用规范
• Top5
算法
解析：这个只是提一下，一般业务也不会用到什么算法。顶多是用个遍历什么的，不要多使用多层遍历就行了，不然时间复杂度太高，消耗性能。
• 如果你掌握了以上几个案例，那你基本解决了咱项目的95%以上的性能问题。看上去也并不难吧，现在就着手动起来吧，排查一个坑，便少一个坑，少一份事故风险。