Java：如何去优雅地优化接口

声明：

• 原作者：天机术士
• 文章来源：http://b.nxw.so/1jSSgg

目录

• 背景

• 哪些问题会引起接口性能问题

• 问题解决

• 总结

背景

我负责的系统在去年初就完成了功能上的建设，然后开始进入到推广阶段。随着推广的逐步深入，收到了很多好评的同时也收到了很多对性能的吐槽。

刚刚收到吐槽的时候，我们的心情是这样的：

当越来越多对性能的吐槽反馈到我们这里的时候，我们意识到，接口性能的问题的优先级必须提高了。

然后我们就跟踪了 1 周的接口性能监控，这个时候我们的心情是这样的：

有 20 多个慢接口，5 个接口响应时间超过 5s，1 个超过 10s，其余的都在 2s 以上，稳定性不足 99.8%。

作为一个优秀的后端程序员，这个数据肯定是不能忍的，我们马上就进入了漫长的接口优化之路。本文就是对我们漫长工作历程的一个总结。

哪些问题会引起接口性能问题

这个问题的答案非常多，需要根据自己的业务场景具体分析。

这里做一个不完全的总结：

• 数据库慢查询

• 业务逻辑复杂

• 线程池设计不合理

• 锁设计不合理

• 机器问题（fullGC，机器重启，线程打满）

• 万金油解决方式

问题解决

| 慢查询（基于 mysql）

①深度分页

所谓的深度分页问题，涉及到 mysql 分页的原理。通常情况下，mysql 的分页是这样写的：

select name,code from student limit 100,20

含义当然就是从 student 表里查 100 到 120 这 20 条数据，mysql 会把前 120 条数据都查出来，抛弃前 100 条，返回 20 条。

当分页所以深度不大的时候当然没问题，随着分页的深入，sql 可能会变成这样：

select name,code from student limit 1000000,20

这个时候，mysql 会查出来 1000020 条数据，抛弃 1000000 条，如此大的数据量，速度一定快不起来。

那如何解决呢？一般情况下，最好的方式是增加一个条件：

select name,code from student where id>1000000  limit 20

这样，mysql 会走主键索引，直接连接到 1000000 处，然后查出来 20 条数据。但是这个方式需要接口的调用方配合改造，把上次查询出来的最大 id 以参数的方式传给接口提供方，会有沟通成本（调用方：老子不改！）。

②未加索引

这个是最容易解决的问题，我们可以通过：

show create table xxxx（表名）

查看某张表的索引。具体加索引的语句网上太多了，不再赘述。不过顺