Java 架构岗 9 大性能优化经验总结，我不允许你不会

性能优化属于 Java 高级岗的必备技能，而且大厂特别喜欢考察，今天主要给大家介绍 9 种性能优化的方法

1.代码

之所以把代码放到第一位，是因为这一点最容易引忽视，比如拿到一个性能优化的需求以后，言必称缓存、异步等。

实际上，第一步就应该是分析相关的代码，找出相应的瓶颈，再来考虑具体的优化策略。

有一些性能问题，完全是由于代码写的不合理，通过直接修改一下代码就能解决问题的，比如 for 循环次数过多、作了很多无谓的条件判断、相同逻辑重复多次等，这样的优化成本是最低的。

2.数据库

1.SQL 优化

这里以 MySQL 为例，最常见的方式是，由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的 SQL，然后使用 explain、profile 等工具来逐步调优，最后经过测试达到效果后上线。

这里举几个优化的例子：

1.查询优化

对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2.避免 null 判断

应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

3.避免全表扫描

应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。

应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描。

in 和 not in 也要慎用，否则会导致全表扫描，如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

4.大数据量查询

对于多张大数据量的表 JOIN，要先分页再 JOIN，否则逻辑读会很高。

5.合理使用索引

索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。

一个表的索引数最好不要超过 6 个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。

6.多使用数字型字段

尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。

这是因为引擎在处理查询和连 接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

7.避免大数量

尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

8.避免大事务

尽量避免大事务操作，提高系统并发能力。

2.连接池调优

我们的应用为了实现数据库连接的高效获取、对数据库连接的限流等目的，通常会采用连接池类的方案，即每一个应用节点都管理了一个到各个数据库的连接池。

随着业务访问量或者数据量的增长，原有的连接池参数可能不能很好地满足需求，这个时候就需要结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量作一个综合的判断，通过反复的几次调试得到最终的调优参数。

更加全面深入的 MySQL 性能优化，请查看：mysql面试调优教程

3.架构层面

这一类调优包括读写分离、多从库负载均衡、水平和垂直分库分表等方面，一般需要的改动较大，但是频率没有 SQL 调优高，而且一般需要 DBA 来配合参与。

详细的分库分表、读写分离，请查看：mysql面试调优教程

3.分布式缓存

缓存可以称的上是性能优化的利器，缓存主要用来存放那些读写比很高、很少变化的数据。

什么情况适合用缓存？考虑以下两种场景：

•  短时间内相同数据重复查询多次且数据更新不频繁，这个时候可以选择先从缓存查询，查询不到再从数据库加载并回设到缓存的方式。此种场景较适合用单机缓存。

•  高并发查询热点数据，后端数据库不堪重负，可以用缓存来扛。

使用缓存需要注意的问题：

1.避免缓存失效

把频繁修改的数据放入缓存，容易出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效的情形，徒增系统负担。

2.缓存热点数据

缓存使用的内存资源非常宝贵，只能将最新访问的数据缓存起来，而把历史数据清理出缓存，即缓存资源应该留给 20%的热点数据。

 3.数据不一致性

一般会对缓存设置失效时间，超过失效时间，就要从数据库重新加载。

因此应用要忍受一定时间的数据不一致，另一种策略是数据更新时立即更新缓存，不过这也会带来更多的系统开销和事务一致性的问题。

 4.缓存可用性

业务发展到一定阶段时，缓存会承担大部分数据访问的压力，数据库已经习惯了有缓存的日子，所以当缓存服务器崩溃时，数据库会因为完全不能承受如此大的压力而宕机，进而导致整个网站不可用，这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复网站访问。

解决方式：

1）缓存热备（当某台服务器宕机时，将缓存访问切换到热备服务器上；

2）缓存服务器集群。

5. 缓存预热

缓存中存放的是热点数据，热点数据是缓存系统用 LRU 对不断访问的数据筛选出来的，这个过程需要较长的时间。

新启动的缓存系统没有任何数据，此时系统的性能和数据库负载都不太好。因此可以选择在启动缓存是就把热点数据预加载好。

 6.缓存穿透

因为不恰当的业务或恶意攻击，持续高并发地访问某一个不存在的数据，如果缓存不保存该数据，就会有大量的请求压力落在数据库上。

简单的解决方式是把请求的不存在的数据也放进缓存，其 value 是 null。

如果还想全面了解缓存的 5 大难题，《如何解决Redis缓存雪崩、缓存穿透、缓存并发等5大难题》有更加深入全面的讲解。

4.异步化

针对某些客户端的请求，在服务端可能需要针对这些请求做一些附属的事情，这些事情其实用户并不关心或者用户不需要立即拿到这些事情的处理结果，这种情况就比较适合用异步的方式处理这些事情。

异步化的作用：

•  缩短接口响应时间，使用户的请求快速返回，用户体验更好。

•  避免线程长时间处于运行状态，这样会引起服务线程池的可用线程长时间不够用，进而引起线程池任务队列长度增大，从而阻塞更多请求任务，使得更多请求得不到技术处理。

•  线程长时间处于运行状态，可能还会引起系统 Load、CPU 使用率、机器整体性能下降等一系列问题，甚至引发雪崩。异步的思路可以在不增加机器数和 CPU 数的情况下，有效解决这个问题。

比如：使用消息队列（MQ）中间件服务，MQ 天生就是异步的。

一些额外的任务，可能不需要我这个系统来处理，但是需要其他系统来处理，这个时候可以先把它封装成一个消息，扔到消息队列里面，通过消息中间件的可靠性保证把消息投递到关心它的系统，然后让这个系统来做相应的处理。

再比如 C 端在完成一个提单动作以后，可能需要其它端做一系列的事情，但是这些事情的结果不会立刻对 C 端用户产生影响，那么就可以先把 C 端下单的请求响应先返回给用户，返回之前往 MQ 中发一个消息即可，而且这些事情理应不是 C 端的负责范围，所以这个时候用 MQ 的方式，来解决这个问题最合适。

5.Web 前段

Web 前端指网站业务逻辑之前的部分，包括：

• 浏览器加载

• 网站视图模型

• 图片服务

• CDN 服务等

主要优化手段有优化浏览器访问，使用反向代理，CDN 等。

1.浏览器访问优化

(1)减少 http 请求

HTTP 协议是无状态的应用层协议，意味着每次 HTTP 请求都需要简历通信链路，进行数据传输，而在服务器端，每个 HTTP 都需要启动独立的线程去处理，这些通信和服务的开销都很昂贵，减少 HTTP 请求的数目可有效提高访问性能。

减少 HTTP 请求的主要手段是:

•  合并 CSS，以及压缩 CSS 大小

•  合并 JavaScript，以及压缩 JS 大小

•  合并图片

将浏览器一次访问需要的 JavaScript,CSS 合并成一个文件，这样浏览器就只需要一次请求。多张图片合并成一张，如果每张图片都有不同的超链接，可通过 CSS 偏移响应鼠标点击操作，构造不同的 URL。

(2)使用浏览器缓存

对一个网站而言，CSS,JavaScript,Logo,图标等这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次 HTTP 请求都需要的，如果将这些文件缓存在浏览器中，可以极好地改善性能。通过设置 HTTP 头中 Cache-Control 和 Expires 属性，可设定浏览器缓存，缓存时间可以是数天甚至是几个月。有时候，静态资源文件变化需要及时应用到客户端浏览器，这种情况可以通过改变文件名实现，比如一般会在 JavaScript 后面加上一个版本号，使浏览器刷新修改的文件。

(3)启用压缩

在服务器端对文件进行压缩，在浏览器端对文件解压缩，可有效较少通信传输的数据量。文本文件的压缩效率科大 80%以上。

(4)CSS 放在页面最上面，JavaScript 放在页面最下面

浏览器会在下载完全部 CSS 之后对整个页面进行渲染，因此最好的做法是将 CSS 放在页面最上面，让浏览器尽快下载 CSS。JS 则想法，浏览器在加载 JS 后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此 JS 最好放在页面最下面。

(5)减少 Cookie 传输

一方面，Cookie 包含在每次请求和响应中，太大的 Cookie 会严重影响数据传输，因此哪些数据需要写入 Cookie 需要慎重考虑，尽量减少 Cookie 中传输的数据量。另一方面，对于某些静态资源的访问，如 CSS,JS 等，发送 Cookie 没有意义，可以考虑静态资源使用独立域名访问，避免请求静态资源时发送 Cookie，减少 Cookie 传输的次数。

2.CDN 加速

CDN(Content Distribute Network,内存分发网络)的本质上仍然是一个缓存，而且将数据缓存在离用户最近的地方，是用户以最快速度获取数据，即所谓网络访问第一跳。

CDN 一般缓存的是静态资源，如图片，文件，CSS，Script 脚本，静态网页等，但是这些文件访问频率很高，将其缓存在 CDN 可极大改善网页的打开速度。

3.反向代理

传统代理服务器位于浏览器一侧，代理浏览器将 HTTP 请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站 Web 服务器接收 HTTP 请求。

和传统代理服务器可以保护浏览器安全一样，反向代理服务器也具有保护网站安全的作用，来自互联网的访问请求必须经过代理服务器，相当于在 Web 服务器和可能的网络攻击之间建立了一个屏障。

除了安全功能，代理服务器也可以通过配置缓存功能加速 Web 请求，当用户第一次访问静态内容的时候，静态内容就被缓存在反向代理服务器上，这样当其他用户访问该静态内容的时候，就可以直接从反向代理服务器返回，加速 Web 请求响应速度，减轻服务器负载要。

6.服务化

做服务化最基础的是按业务做服务拆分，避免跨业务间的互相影响，数据和服务同时拆分。同一个业务内部我们还按计算密集型/IO 密集型的服务拆分、C 端/B 端服务拆分、核心/非核心服务拆分、高频服务单独部署等原则做拆分。

7.硬件升级

硬件问题对性能的影响不容忽视。

举一个例子：一个 DB 集群经常有慢 SQL 报警，业务排查下来发现 SQL 都很简单，该做的索引优化也都做了，后来 DBA 同学帮忙定位到问题是硬件过旧导致，将机械硬盘升级成固态硬盘之后报警立马消失了，效果立竿见影！

8.搜索引擎

复杂查询以及一些聚合计算不适合在数据库中做，可以利用搜索引擎来实现，另外搜索引擎还可以帮我们很好的解决跨库、跨数据源检索的场景。

9.产品逻辑优化

业务逻辑优化经常会容易被忽略，但效果却往往比数据库性能优化、JVM调优之类的来的更明显。

举一个例子，12306 春运抢火车票的场景，由于访问的人多，用户点击“查票”之后系统会非常卡，进度条非常慢，作为用户，我们会习惯性的再去点“查票”，可能会连续点个好几次。

假设平均一个用户点 5 次，则后端系统负载就增加了 5 倍！而其中 80%的请求是重复请求。

这个时候我们可以通过产品逻辑的方式来优化，比如，在用户点击查询之后将“按钮置灰”，或者通过 JS 控制 xx 秒只能只能提交一次请求等，有效的拦截了 80%的无效流量。

原文：https://www.cnblogs.com/mikechenshare/p/16594247.html

如果感觉本文对你有帮助，点赞关注支持一下，想要了解更多 Java 后端，大数据，算法领域最新资讯可以关注我公众号【架构师老毕】私信 666 还可获取更多 Java 后端，大数据，算法 PDF+大厂最新面试题整理+视频精讲