背过阿里技术官整理的四大JVM调优模块，简历至少升至30K

一个 web 应用不是一个孤立的个体，它是一个系统的部分，系统中的每一部分都会影响整个系统的性能，而并发量就是这个系统最重要的组成部分之一，它最大程度的影响着用户体验度，就像是一条高速公路，在这条高速上奔跑的汽车最关心的不就是这条高速是否会堵车啊，所以在高速设计（系统开发）的时候就要着手考虑这件事，尤其是现在的生活中，很多的朋友在面试的时候也经常被问到一个问题：JVM调优，那不清楚应该怎么处理怎么办，没关系，我来了，看完这篇文章，哪怕你从来没有调优经验也可以和面试官扯皮
个人公众号：Java架构师联盟，每日更新技术好文
话不多说，看重点

1. 常用的性能评价/测试指标

在调优之前，起码你要清楚你再进行调优的时候都要有哪些关注点吧，知己知彼才能百战不殆啊，那我们就来看一下都有哪些常用的性能测试指标

1.1 响应时间

提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。 常用操作的响应时间列表：

1.2 并发数

同一时刻，对服务器有实际交互的请求数。

和网站在线用户数的关联：1000 个同时在线用户数，可以估计并发数在 5%到 15%之间， 也就是同时并发数在 50~150 之间。

1.3 吞吐量

对单位时间内完成的工作量(请求)的量度

1.4 关系

系统吞吐量和系统并发数以及响应时间的关系：

以高速公路的通行状况：

吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费）， 并发数是高速公路上的正在行驶的车辆数目，响应时间是车速。

车辆很少时，车速很快。但是收到的高速费也相应较少；随着高速公路上车辆数目的增多， 车速略受影响，但是收到的高速费增加很快；

随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降；

如果车流量继续增加，超过某个极限后，任何偶然因素都会导致高速全部瘫痪，车走不动， 当然后也收不着，而高速公路成了停车场（资源耗尽）。

2. 常用的性能优化手段

在知道了常用的性能优化测评的指标之后，那我们看一下平时的时候都会有哪些相应的优化手段，这样，两方进行结合，就是我们的最佳的优化手段

2.1 避免过早优化

不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。

所以，我们应该编写清晰，直接，易读和易理解的代码，真正的优化应该留到以后，等到性能分析表明优化措施有巨大的收益时再进行。

但是过早优化，不表示我们应该编写已经知道的对性能不好的的代码结构。

2.2 进行系统性能测试

所有的性能调优，都有应该建立在性能测试的基础上，直觉很重要，但是要用数据说话，可 以推测，但是要通过测试求证。

2.3 寻找系统瓶颈，分而治之，逐步优化

性能测试后，对整个请求经历的各个环节进行分析，排查出现性能瓶颈的地方，定位问题， 分析影响性能的的主要因素是什么？内存、磁盘 IO、网络、CPU，还是代码问题？架构设计不足？或者确实是系统资源不足？

2.4 前端优化常用手段

2.4.1 浏览器/App

1、减少请求数；

2、合并 CSS，Js，图片使用客户端缓冲；

3、静态资源文件缓存在浏览器中，有关的属性 Cache-Control 和 Expires

4、如果文件发生了变化，需要更新，则通过改变文件名来解决。 启用压缩

5、减少网络传输量，但会给浏览器和服务器带来性能的压力，需要权衡使用。 资源文件加载顺序

6、css 放在页面最上面，js 放在最下面减少 Cookie 传输

7、cookie 包含在每次的请求和响应中，因此哪些数据写入 cookie 需要慎重考虑给用户一个提示，有时候在前端给用户一个提示，就能收到良好的效果。毕竟用户需要的是不要不理他。

2.4.2 CDN 加速

CDN，又称内容分发网络，本质仍然是一个缓存，而且是将数据缓存在用户最近的地方。 无法自行实现 CDN 的时候&#x