一、耗时统计在做接口的性能优化时最重要的是知道时间消耗在哪里。优先使用 Arthas 进行耗时统计。不需要写冗余代码无侵入。https://blog.csdn.net/sinat_32502451/article/details/142960019可以用StopWatch进行耗时统计。需要写一些代码。详情见https://blog.csdn.net/sinat_32502451/article/details/148350451二、链路追踪如果团队使用了Skywalking可以用来进行链路追踪耗时统计。时间主要消耗在哪些服务哪些方法通过traceId一看便知。Skywalking非常有用哪怕项目里没有也可以积极推进并接入Skywalking。三、性能监控如果团队里面有用到一些性能监控的工具比如Grafana、Prometheus。可以多看下接口的请求数、响应时间、服务器的CPU、GcCount等。四、线程池多线程、异步如果多个任务之间不存在先后关系没有强依赖可以使用线程池做多线程、异步。如果接口中存在多个任务可以考虑使用多线程。如果接口中有某个任务比较耗时可以考虑使用异步。CompletableFuture类能够开多线程处理多个任务还能处理异步回调。还能将多个任务合并成一个设置阻塞时间。非常实用。详情见https://blog.csdn.net/sinat_32502451/article/details/133955576线程池调优详情见https://blog.csdn.net/sinat_32502451/article/details/148350537五、MQMQ的使用场景: 异步解耦削峰。如果存在耗时的任务或功能对性能的要求比较高可以使用MQ做异步。线程池也可以异步处理但如果系统挂了线程池也会失效MQ则不会。MQ做异步还有重试机制。六、数据库数据表加索引数据库最常见的优化就是加索引。索引能够极大地提升数据表查询的速度。常用的区分度高的字段可以尝试加索引。如果经常查询的有多个字段可以考虑查询条件是否符合最左匹配原则符合的话用复合索引。批量处理–数据表接口代码在做批量处理时一定要注意不要在for循环中调用数据库/缓存不仅性能极差还有连接数耗尽的可能。数据表的批量处理详情见https://blog.csdn.net/sinat_32502451/article/details/148350849Explain接口中的sql比较慢时可以用 Explain查看执行计划做性能优化。详情见 https://segmentfault.com/a/1190000008131735分库分表数据表的数据量大可以分库分表。详情见 https://blog.csdn.net/sinat_32502451/article/details/140732625七、缓存加缓存Redis缓存的处理速度远远快于数据库/网络这些IO。在做性能优化时如果数据库/网络太慢经常会用到Redis缓存。加缓存有几点要注意1.如果在查询时使用了缓存那么在更新(删除、插入)之后必须处理缓存(一般是更新DB后删除缓存)让数据最终一致。2.实时数据频繁更新的数据最好不要加缓存。3.如果不是频繁更新的数据又没法在数据变更时处理缓存比如调用其他系统的接口可以尝试加较短时间的缓存比如1分钟。详情见 https://blog.csdn.net/sinat_32502451/article/details/139545057批量处理–缓存Redis的execute()可以在一次连接中处理多个命令。Redis的execute()详情见https://blog.csdn.net/sinat_32502451/article/details/134366504Pipeline (管道) 可以一次性发送多条命令并在执行完后一次性将结果返回。Redis的管理操作详情见: https://blog.csdn.net/sinat_32502451/article/details/134366490数据预热使用定时任务定时去查询数据或者是通过前置过滤器提前预热。查询之后数据进入缓存那么用户再去查时速度就会快很多。这也是一种很常见的性能优化方式。·八、服务器服务器的状态服务器是否正常启动。在调用接口时服务器的CPU、GcCount是否正常。九、优化服务链路如果接口的服务链路比较复杂可以试着优化服务链路。比如A服务中分别调用了B,C,D服务那可以试着将BCD服务的内容合并到一个服务中只做一次调用。比如服务链路为 A-B-C-D可以试着缩短服务链路由 A-D这样消耗的时间也会变短。十、去掉冗余逻辑如果接口复用了项目中其他的方法/代码可以看是否有冗余的逻辑如果有冗余的考虑能否抽取可用逻辑去掉冗余的逻辑。