JVM概览
1java启动顺序
启动顺序：启动类加载器->扩展类加载器->应用类加载器
2类文件结构
魔数/文件格式版本/常量池/访问标志/当前类/超类/接口/字段/方法/属性
零成本实现原则：不需要为用不到的功能付出代价。更进一步，你要使用的东西，性能已经非常好，手动优化也不会做的更好了
即时编译JIT
编译的单元是方法和循环对执行的最频繁的部分进行编译和优化
4内存管理
5线程和内存模型
6JVM版本
7JVM监控和工具
•Java管理扩展•其他方式：JVMTI•SA
硬件与操作系统
2内存
•CPU的发展远快于存储的发展
高速缓存
L1/L2----核心独有，L3核心共用，通过北桥连接到主存
高速缓存一致性协议MESI
•已修改（Modified),但尚未刷新到主存•独占（exclusive),只出现在当前高速缓存中，但数据和主存一致•共享（shared),可能出现在其他高速缓存中，但数据和主存一致•无效（invalid),可能未被使用，会尽快丢弃
3现代处理器
翻译后备缓冲器的高速缓存分支预测和推测执行硬件存储模型--javac,jit,cpu都允许改变执行顺序（storeload)
4操作系统
进程抢占的稀缺资源：CPU时间/内存
内存管理单元以及页表的虚拟寻址是内存访问的关键，以保证一个进程的内存资源不被其他进程破坏
1调度器
线程放弃时间片的方式：sleep/wait
2时间问题
与操作系统有关
3上下文切换
从用户模式切到内核模式会损失很大性能
处理方式：vDSO----用内存代替调用
5简单系统调用层次
操作系统及硬件/JVM或容器/应用程序本身/外部系统/外部请求流量
6基本的探测策略
1利用CPU
Vmstat命令
可运行线程（r)/阻塞线程（b)
交换区（swpd)/空闲区/缓冲区/高速缓存
磁盘交换的内存量（si)/交换到磁盘上的内存量（so)
从IO设备接到个数（bi)/发送到IO设备的块个数（bo)
中断次数（in)/上下文切换次数
用户时间
2垃圾收集
垃圾收集日志的成本很低，可以在生产环境上开启
内核旁路IO
4机械共鸣
作为一个赛车手，你不必成为工程师，但量一定要有机械共鸣。---JackieStewart
7虚拟化
8JVM和操作系统
性能测试模式与反模式
1性能测试的类型
好的性能测试是量化的
•延迟测试/SLA•吞吐量测试/系统开始降级之前得到的最大吞吐量•负载测试•压力测试/缓慢增加并发，直到数据开始下降•耐久性测试/以天为单位，缓慢内存泄漏，高速缓存污染，内存碎片化，fullgc•容量规划测试•退化测试
2最佳实践入门
1自上而下的测试方式
从整个应用程序性能行为入手
3创建测试环境
3确定能要求
将系统作为一个整体，考虑对用户以及管理层重要的观测量
4JAVA特有问题
需要确认哪些方法被JIT编译了
未编译的原因：
运行频率不够高方法太大
5将性能测试作为软件生命周期的一部分
3性能反模式
厌倦/填充简历/同侪压力/缺乏理解/被错误理解的问题或不存在的问题
1被热门技术分心
•描述:使用最新或最酷的热门技术•评论：这是初期故障，我们需要弄清真相•现实：只是瞎猜/没有理解新技术/网络上的资料不一定是企业应用的案例，可能只是小规模实践•讨论：任何性能问题都应该看一下是否是由于采用新技术引起•解决：通过测量确定真正瓶颈/确定新组件有足够的日志/不能看演示，要看最佳实践/确保团队了解了新技术，并可以建立最佳实践
2被简单分心
•描述：团队只看中系统中最简单的部分，而不是系统整体•评论：先从我们理解的部分入手吧,这是John写的，他正在休假，等他回来吧•现实：原始开发人员了解自己编写的部分/没有知识共享或结对编程，成为领域单一专家•讨论：是一种防御性策略，不愿意接触不熟悉的领域•解决：对于测量确定瓶颈/向领域专家求助/确保开发人员了解系统所有组件
3性能调优天才
•描述:管理层相信天才黑客的存在•评论：我想我知道问题出在哪里了•现实：魔法师或超级英雄唯一可能做的事情就是奇装异服•讨论：会使团队有疏离感/促进分享知识•解决：测量确实瓶颈/保证专家愿意分享
5把责任归咎给驴
•描述：某些组件总会被当成问题所在，虽然他们与问题毫无关系•评论：总是XX的问题•现实：没有经过充分分析/怀疑对象成为调查唯一目标/不愿意进行更大范围的研究调查•讨论：通过管理或业务人员表现/技术人员成为牺牲品•解决：不要急于得出结论/认真执行分析/向所有干系人通告结果
6忽略大局
•描述：只做小理改，没有意识到整体影响•评论：如果只修改这些设置/如果能加快分派时间•现实：没有充分理解更改的影响/没有在新设置在对系统全面分析/微基准测试对整体系统的影响不确定•讨论：jvm有上百个开关/性能调优是统计学活动•解决：生产环境中测量/每次改动一个开关/测试环境压力点一致
7用户验收环境就是我的计算机
•描述：在自己的机器上测试•评论：和生产环境完全一致的用户验收测试环境成本太高了•现实：环境差异造成的服务中断成本比建一个测试环境的成本要大的多•讨论：测试环境必须与生产环境一致•解决：评估事故成本/建立与生产环境一致的测试环境
8类似生产环境的数据很难表示
•描述：简化测试数据集•评论：数据保持同步太难了/数据符合预期太难了/生产环境数据受保护•现实：用户测试环境中的数据必须与生产环境中类似/可以混淆数据•讨论：假数据的测试结果是虚假的/不符合预期•解决：迁移生产数据到测试环境/对发布做好准备
5认知偏差与性能测试
认知偏差是一种会导致人脑得出错误结论的心理效应。问题的重点在于表现出这种偏差的人通常认识不到这一点，而且很可能认为自己是理性的。
1还原思维论
认识偏差认为如果能把一个系统分成足够小的组成部分，就可以通过理解每一部分来理解他。忽略了系统的复杂性
2确认偏差
当选择一个糟糕的测试集或没有结果进行统计分析时，会引入确认偏差
3战争迷雾
在性能不及预期或是服务中断时表现出来，如：
更改了基础设施，没有意识到会产生影响更改了依赖的库在最忙的时候遇到了奇怪的bug
错把行动当成了速度要把紧张的情绪从环境中抽离出来
4风险偏差
抗拒风险，厌恶改变
小的，经过计算的风险是可以接受的。
5坎尔斯伯格悖论
与未知的未知相比，人们更喜欢已知的未知
文章为作者独立观点，不代表股票交易接口观点
股民评论