影响一个系统性能的方方面面
一个web应用不是一个孤立的个体，它是一个系统的部分，系统中的每一部分都会影响整个系统的性能
常用的性能评价/测试指标
响应时间
提交请求和返回该请求的响应之间使用的时间，一般比较关注平均响应时间。
常用操作的响应时间列表：
|
操作 |
响应时间 |
|
打开一个站点 |
几秒 |
|
数据库查询一条记录（有索引） |
十几毫秒 |
|
机械磁盘一次寻址定位 |
4毫秒 |
|
从机械磁盘顺序读取1M数据 |
2毫秒 |
|
从SSD磁盘顺序读取1M数据 |
0.3毫秒 |
|
从远程分布式换成Redis读取一个数据 |
0.5毫秒 |
|
从内存读取1M数据 |
十几微妙 |
|
Java程序本地方法调用 |
几微妙 |
|
网络传输2Kb数据 |
1微妙 |
并发数
同一时刻，对服务器有实际交互的请求数。
和网站在线用户数的关联：1000个同时在线用户数，可以估计并发数在5%到15%之间，也就是同时并发数在50~150之间。
吞吐量
对单位时间内完成的工作量(请求)的量度
关系
系统吞吐量和系统并发数以及响应时间的关系：
理解为高速公路的通行状况：
吞吐量是每天通过收费站的车辆数目（可以换算成收费站收取的高速费），
并发数是高速公路上的正在行驶的车辆数目，
响应时间是车速。
车辆很少时，车速很快。但是收到的高速费也相应较少；随着高速公路上车辆数目的增多，车速略受影响，但是收到的高速费增加很快；
随着车辆的继续增加，车速变得越来越慢，高速公路越来越堵，收费不增反降；
如果车流量继续增加，超过某个极限后，任务偶然因素都会导致高速全部瘫痪，车走不动，当然后也收不着，而高速公路成了停车场（资源耗尽）。
常用的性能优化手段
避免过早优化
不应该把大量的时间耗费在小的性能改进上，过早考虑优化是所有噩梦的根源。
所以，我们应该编写清晰，直接，易读和易理解的代码，真正的优化应该留到以后，等到性能分析表明优化措施有巨大的收益时再进行。
但是过早优化，不表示我们应该编写已经知道的对性能不好的的代码结构。如《4、编写高效优雅Java程序》中的《15、当心字符串连接的性能》所说的部分。
进行系统性能测试
所有的性能调优，都有应该建立在性能测试的基础上，直觉很重要，但是要用数据说话，可以推测，但是要通过测试求证。
寻找系统瓶颈，分而治之，逐步优化
性能测试后，对整个请求经历的各个环节进行分析，排查出现性能瓶颈的地方，定位问题，分析影响性能的的主要因素是什么？内存、磁盘IO、网络、CPU，还是代码问题？架构设计不足？或者确实是系统资源不足？
前端优化常用手段
浏览器/App
减少请求数；
使用客户端缓冲；
启用压缩
资源文件加载顺序
减少Cookie传输
CDN加速
反向代理缓存
WEB组件分离
应用服务性能优化
缓存
网站性能优化第一定律：优先考虑使用缓存优化性能
Mark老师的推论：缓存离用户越近越好
缓存的基本原理和本质
合理使用缓冲的准则
分布式缓存与一致性哈希
异步
同步和异步，阻塞和非阻塞
常见异步的手段
Servlet异步
多线程
消息队列
集群
程序
代码级别
选择合适的数据结构
选择更优的算法
编写更少的代码
并发编程
充分利用CPU多核，
尽量使用线程池，合理设置线程数量，尽量使用JDK提供的各种并发框架和工具
实现线程安全的类，避免线程安全问题
同步下减少锁的竞争
缩小锁的范围，减少锁的粒度，锁分段，替换独占锁，读写锁，CAS代替锁，ThreadLocal等等
资源的复用
减少开销很大的系统资源的创建和销毁
单例模式
池化技术
JVM
与JIT编译器相关的优化
热点编译的概念
选择编译器类型
-server，-client，-XX:+TieredCompilation
代码缓存相关
–XX:ReservedCodeCacheSize=N
编译阈值
编译线程
方法内联
逃逸分析
GC调优
目的
调优的原则和步骤
学会阅读GC日志
其他与GC相关的参数
推荐策略
调优实战
不同的内存大小
不同的GC回收器
存储性能优化
尽量使用SSD
定时清理数据或者按数据的性质分开存放
结果集处理
来源：https://blog.csdn.net/fuqianming/article/details/96337845