JVM规范：
Class文件格式
数字的内部表示和存储
-Byte -128 to 127
returnAddress数据类型定义：
-指向操作码的指针。不对应java数据类型，不能再运行时修改。
定义PC
堆
栈
方法区
JVM运行机制：
JVM启动流程：
如图：
JVM基本结构：
如图：
PC寄存器：
- 每个线程拥有一个PC寄存器
- 在线程创建时 创建
- 指向吓一跳指令的地址
- 执行本地方法时，PC的值为undefined
方法区：
- 保存类的源信息
-类的常量池
-字段、方法的信息
-方法字节码
- 通常和永久去（Perm）关联再一起
Java堆：
- 和程序开发密切相关
- 应用系统对象都保存在java堆中
- 所有的线程共享java堆
- 对分代GC来说，堆也是分代的
- GC的主要工作空间
-----------------------------------------
| | | | |
| eden | s0 | s1 | tenured
| | | | |
-----------------------------------------
复制算法
java栈：
- 线程私有的
- 栈由一系列的帧组成（因此java栈也叫作帧栈）
- 栈保存一个方法的局部变量、操作数栈、常量池指针
- 每一次方法调用创建一个帧，并压栈
内存模型：
- 每一个线程有一个工作内存和主存独立
- 工作内存存放主存中变量值的拷贝
----------------
| 线程执行引擎 |
----------------
| ^
assign | | use
V |
----------------
| 线程工作内存 |
----------------
^ |
read,load | | store,write
| V
----------------
| 主内存 |
----------------
注：当数据从主存复制到工作内存是，必须出现两个动作：
1：与主内存执行读（read）操作
2：由工作内存执行相应的load操作
当数据从工作内存拷贝到主内存时，也出现两个操作：
1：由工作内存执行的存储（store）操作
2：由主内存执行相应的写（write）操作
每一个操作都是原子的，即执行期间不会被中断
对于普通变量，一个线程中更新的值，不能马上反应再其他的变量中
如果需要在其它线程中立即可见，需要是用volatile关键字
可见性：
- 一个线程修改了变量，其他线程可以立即知道
- 保证线程可见性的方法：
- volatile
- synchronized（unlock之前，写变量值会主存）
- final(一旦初始化完成，其他线程就可见)
有序性：
- 在本线程内，操作都是有序的
- 在线程外观察，操作都是无序的
JVM常用的配置参数：
Trace跟踪参数：
*：-verbose:gc
*:-XX:+pringGC
*:可以打印GC的简要信息
---[GC 4790K->364K(15782K),0.001606 secs]
---[GC 4790K->364K(15782K),0.001474 secs]
---[GC 4790K->364K(15782K),0.001563 secs]
---[GC 4790K->364K(15782K),0.001682 secs]
*-XX:+PrintGCDetails
-打印GC详细信息
*-XX:+PrintGCTimeStamps
-打印GC发生的时间戳
*-Xloggc:log/gc.log
-指定GC log的位置，以文件输出
- 帮助开发人员分析问题
*-XX:+PringHeapAtGC
-每一次GC前后，都打印堆信息
*-XX:+TraceClassLoading
-监控类的加载
*-XX:+PrintClassHistogram
-按下Ctrl + Break以后，打印类的信息
分别显示：序号、实例数量、总大小、类型 （这个参数可以看各个数据类型的使用情况）
堆的分配参数：
-Xmx -Xms
-指定最大堆和最小堆
-Xmx20m -Xms5m
-Xmn
-设置新生代的大小
-XX:NewRatio
-新生代（eden + 2*s）和老年代（不包含永久区）的比值
-4表示 新生代:老年代 = 1:4,即年轻代占堆的1/5
-XX:SurvivorRatio
-设置两个Survivor区和eden的比
-8表示 两个Survivor：eden = 2:8 一个Survivor也就是占年轻代1/10
-XX:+HeapDumpOnOutOfMemoryError
-OOM时导出到堆
-XX:+HeapDumpPath
-导出OOM的路劲
-XX:OnOutOfMemoryError
-在oom时，执行一个脚本
-"-XX:OnOutOfMemoryError=xxxx.bat %P" %P java进程ID 当程序oom时就会执行bat文件 可以用来发邮件甚至重启服务
堆的分配参数总结：
根据实际情况调整新生代和心存代的大小
官方推荐新生代占堆的3/8
辛存代占新生代的1/10
在oom时，记得Dump出堆，确保可以排查现场问题
永久区分配参数：
-XX:PermSize -XX:MaxPermSize
-设置永久带的初始空间和最大空间
-他们表示，一个系统可以容纳多少个类型
栈大小分配：
-Xss
-通常只有几百K
-决定了函数调用的深度
-每个线程都有独立的栈空间
-局部变量、参数 分配在栈上
GC算法与种类：
GC的概念：垃圾收集，在java中，GC的对象是堆空间和永久区。
GC算法：
引用计数法：
引用计数法的概念
对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1，当引用失效时，引用计数器就减1，只要对象A的引用计数器的值为0,
则A对象就不可能再被使用。
引用计数法的问题：
-引用计数法伴随着加法和减法，影响性能。
-很难处理循环引用。
标记-清除算法：
概念：
标记-清除算法分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段，首先通过根节点，标记所有从根节点开始的可达对象。
因此，从未被标记的对象就是未被引用的垃圾对象。然后在清除阶段，清除所有未被标记的对象。
标记-压缩算法：
概念：
标记-压缩算法适合用于存活对象较多的场合，如老年代。它在标记-清除算法的基础上做了一些优化。和标记清除算法一样。标记压缩也需要从根节点开始。
对所有可达对象做一次标记。但之后，它并不简单的清除未标记对象，而是将所有的存活对象压缩到内存的一端之后，清理边界外所有空间。
复制算法:
-与标记-清除算法相比，复制算法是一种相对高效的回收方法
-不适用于存活对象比较多的场合
-将原有内存空间分为两块，每次只使用其中一块，在垃圾收回时，将正在使用的内存中存活的对象复制到未使用的内存块中，之后，清除真的使用的内存块
中的所有对象，交换两个内存的角色，完成垃圾回收。
复制算法的问题：
空间浪费，需预留一半的空间。
分代思想:
-根据对象的存活周期进行分代，短命对象归为新生代，长命对象归为老年代。
-根据不同代的特点，选取合适的收集算法：
-少量对象存活适合复制算法
-大量对象存活适合标记清理或者标记压缩
GC算法总结：所有的算法，需要一个识别的垃圾对象，因此需要给出一个可触及性的定义。
引用计数
-没有被java采用
标记-清除
标记-压缩
复制算法
-新生代
可触及性：（什么是根：栈中的对象，全局对象，JNI方法栈中引用的对象）
可触及：
-从根节点可以触及到这个对象
可复活：
-一旦所有引用被释放，就可复活的状态
-因为在finallize()中可能复活该对象
不可触及的：
-在finallze()后，可能进入不可触及的状态
-不可触及的对象不可能复活
-可以回收
Stop-The-World
是什么：
-java中一种全局暂停的现象
-全局停顿，所有java代码停止，native代码可以执行，但不能和jvm交互。
-多半由于GC引起
-Dump线程
-死锁检查
-堆Dump
为什么：
-停止制造垃圾才能打扫干净。
危害:
-长时间服务停止，没有响应。
-遇到HA系统，可能引起主备切换，严重危害生产环境。
GC回收器：
GC串行回收器：
-最古老，最稳定
-效率高
-可能会产生较长的停顿
-XX:+UseSerialGC
-新生代、老年代使用串行回收
-新生代复制算法
-老年代标记-压缩算法
GC并行回收器：
ParNew收集器：
-XX:+UseOarNewGC
-新生代并行
-老年代串行
-Serial收集器新生代的并行版本
-复制算法
-多线程，需要多核支持
- -XX:ParallelGCThreads 限制线程数量
Parallel收集器：
-类似ParNew
-新生代复制算法
-老年代 标记-压缩
-更加关注吞吐量
- -XX:+UseParallelGC
-使用parallel收集器+老年代串行
- -XX:+UserParallelOldGC
-使用Parallel收集器+并行老年代
并行回收器的参数：
-XX:MaxGCPauseMills
-最大停顿时间，单位毫秒
-GC尽力保证回收时间不超过设定值
-XX:GCTimeRatio
-0-100的取值范围
-垃圾收集时间占总时间的比
-默认99，即最大允许1%时间做GC
这两个参数是矛盾的。因为停顿时间和吞吐量不可能同时调优
CMS收集器：
-Concurrent Mark Sweep 并发标记清除
-与标记-清除算法
-与标记-压缩相比
-并发阶段会降低吞吐量
-老年代收集器（新生代使用ParNew）
- -XX:+UseConcMarkSweepGC
CMS的运行过程：
-初始标记
-根可以直接关联到的对象
-速度快
-并发标记（和用户线程一起）
-主要标记过程，标记全部对象
-重新标记
由于并发标记时，用户线程任然运行，因此在正式清理前，再做修正
-并发清除（和用户线程一起）
基于标记结果，直接清理对象
CMS的特点：
-尽可能的降低停顿
-会影响系统整体吞吐量和性能
-比如在用户线程运行过程中，分一半CPU去做GC，反应速度就下降一半
-清理不彻底
-因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理
-因为和用户线程一起运行，不能在空间快满时再清理
- -XX:CMSInitiatingOccupancyFraction设置触发GC的阈值
-如果不幸内存预留空间不够，就会引起concurrent failure
GC参数 – CMS收集器
-XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次整理
整理过程是独占的，会引起停顿时间变长
-XX:+CMSFullGCsBeforeCompaction
设置进行几次Full GC后，进行一次碎片整理
-XX:ParallelCMSThreads
设定CMS的线程数量
GC参数整理:
-XX:+UseSerialGC：在新生代和老年代使用串行收集器
-XX:SurvivorRatio：设置eden区大小和survivior区大小的比例
-XX:NewRatio:新生代和老年代的比
-XX:+UseParNewGC：在新生代使用并行收集器
-XX:+UseParallelGC ：新生代使用并行回收收集器
-XX:+UseParallelOldGC：老年代使用并行回收收集器
-XX:ParallelGCThreads：设置用于垃圾回收的线程数
-XX:+UseConcMarkSweepGC：新生代使用并行收集器，老年代使用CMS+串行收集器
-XX:ParallelCMSThreads：设定CMS的线程数量
-XX:CMSInitiatingOccupancyFraction：设置CMS收集器在老年代空间被使用多少后触发
-XX:+UseCMSCompactAtFullCollection：设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片的整理
-XX:CMSFullGCsBeforeCompaction：设定进行多少次CMS垃圾回收后，进行一次内存压缩
-XX:+CMSClassUnloadingEnabled：允许对类元数据进行回收
-XX:CMSInitiatingPermOccupancyFraction：当永久区占用率达到这一百分比时，启动CMS回收
-XX:UseCMSInitiatingOccupancyOnly：表示只在到达阀值的时候，才进行CMS回收
GC参数-Tomcat实例:
环境：
Tomcat7
jsp网站
测试网站吞吐和延时
工具:
JMeter
目的：
让tomcat有一个不错的吞吐量
类装载器：
class装载验证流程：
加载：
装载类的第一个阶段
1：取得累的二进制流
2：转为方法区数据结构
3：在java堆中生成对应的java.lang.Class对象
链接--> 验证：
目的：保证Class流的格式是正确的
-文件格式的验证
-是否以0xCAFEBABE开头
-版本号是否合理
-元数据验证
-是否有父类
-继承了final类？
-非抽象类实现了所有的抽象方法
-字节码验证 (很复杂)
-运行检查
-栈数据类型和操作码数据参数吻合
-跳转指令指定到合理的位置
-符号引用验证
-常量池中描述类是否存在
-访问的方法或字段是否存在且有足够的权限
链接--> 准备：
-分配内存，并为类设置初始值 （方法区中）
public static int v=1;
在准备阶段中，v会被设置为0
在初始化的<clinit>中才会被设置为1
对于static final类型，在准备阶段就会被赋上正确的值
public static final int v=1;
链接--> 解析：
-符号引用替换为直接引用
初始化：
执行类构造器<clinit>
static变量 赋值语句
static{}语句
子类的<clinit>调用前保证父类的<clinit>被调用
<clinit>是线程安全的
什么是类装载器ClassLoader：
ClassLoader是一个抽象类
ClassLoader的实例将读入Java字节码将类装载到JVM中
ClassLoader可以定制，满足不同的字节码流获取方式
ClassLoader负责类装载过程中的加载阶段
系统性能监控
性能监控 - linux：
uptime：
系统时间
运行时间
连接数
1,5,15分钟内的系统平均负载
top：
同uptime
CPU
内存
每个进程占CPU的情况
vmstat：
可以统计系统的CPU，内存，swap，io等情况
CPU占用率很高，上下文切换频繁，说明系统有线程正在频繁切换
pidstat：
细致观察进程
需要安装
sudo apt-get install sysstat
监控CPU
监控IO
监控内存
ps:pidstat -p 2962 -u 1 3 -t (2962/进程号 -u/监控CUP 每秒一次 一共三次 -t/显示线程)
性能监控 - windows：
pslist
-命令行工具
-可用于自动化数据收集
-显示java程序的运行情况
Java自带的工具：
jps：
-列出java进程，类似于ps命令
-参数-q可以指定jps只输出进程ID ，不输出类的短名称
-参数-m可以用于输出传递给Java进程（主函数）的参数
-参数-l可以用于输出主函数的完整路径
-参数-v可以显示传递给JVM的参数
jinfo：
可以用来查看正在运行的Java应用程序的扩展参数，甚至支持在运行时，修改部分参数
-flag <name>：打印指定JVM的参数值
-flag [+|-]<name>：设置指定JVM参数的布尔值
-flag <name>=<value>：设置指定JVM参数的值
jmap：
-生成Java应用程序的堆快照和对象的统计信息
-jmap -histo 2972 >c:\s.txt
Dump堆：
jmap -dump:format=b,file=c:\heap.hprof 2972
jstack：
打印线程dump
-l 打印锁信息
-m 打印java和native的帧信息
-F 强制dump，当jstack没有响应时使用
JConsole：
图形化监控工具
可以查看Java应用程序的运行概况，监控堆信息、永久区使用情况、类加载情况等
- Visual VM：
Visual VM是一个功能强大的多合一故障诊断和性能监控的可视化工具
内存溢出(OOM)的原因：
堆溢出：
占用大量堆空间，直接溢出，Exception in thread "main" java.lang.OutOfMemoryError:
永久区：
生成大量的类，无法回收，Caused by: java.lang.OutOfMemoryError: PermGen space 解决方法：增大Perm区 允许Class回收
Java栈溢出：
这里的栈溢出指，在创建线程的时候，需要为线程分配栈空间，这个栈空间是向操作系统请求的，
如果操作系统无法给出足够的空间，就会抛出OOM。解决方法：减少堆内存 减少线程栈大小
直接内存溢出：
ByteBuffer.allocateDirect()无法从操作系统获得足够的空间，解决方法：减少堆内存 有意触发GC
锁：
对象头Mark：
-Mark Word，对象头的标记，32位
-描述对象的hash、锁信息，垃圾回收标记，年龄
-指向锁记录的指针
-指向monitor的指针
-GC标记
-偏向锁线程ID
偏向锁：
大部分情况是没有竞争的，所以可以通过偏向来提高性能
所谓的偏向，就是偏心，即锁会偏向于当前已经占有锁的线程
将对象头Mark的标记设置为偏向，并将线程ID写入对象头Mark
只要没有竞争，获得偏向锁的线程，在将来进入同步块，不需要做同步
当其他线程请求相同的锁时，偏向模式结束
-XX:+UseBiasedLocking
-默认启用
在竞争激烈的场合，偏向锁会增加系统负担
轻量级锁：BasicObjectLock
-普通的锁处理性能不够理想，轻量级锁是一种快速的锁定方法。
-如果对象没有被锁定
-将对象头的Mark指针保存到锁对象中
-将对象头设置为指向锁的指针（在线程栈空间中）
-如果轻量级锁失败，表示存在竞争，升级为重量级锁（常规锁）
-在没有锁竞争的前提下，减少传统锁使用OS互斥量产生的性能损耗
-在竞争激烈时，轻量级锁会多做很多额外操作，导致性能下降
自旋锁：
-当竞争存在时，如果线程可以很快获得锁，那么可以不在OS层挂起线程，让线程做几个空操作（自旋）
-JDK1.6中-XX:+UseSpinning开启
-JDK1.7中，去掉此参数，改为内置实现
-如果同步块很长，自旋失败，会降低系统性能
-如果同步块很短，自旋成功，节省线程挂起切换时间，提升系统性能
偏向锁，轻量级锁，自旋锁总结：
-不是Java语言层面的锁优化方法
-内置于JVM中的获取锁的优化方法和获取锁的步骤
-偏向锁可用会先尝试偏向锁
-轻量级锁可用会先尝试轻量级锁
-以上都失败，尝试自旋锁
-再失败，尝试普通锁，使用OS互斥量在操作系统层挂起
基于java代码层面锁的优化：
减少锁持有时间，也就是没必要做同步的方法就尽量不要去做同步,能在方法上别在类上
减小锁粒度:
-将大对象，拆成小对象，大大增加并行度，降低锁竞争
-偏向锁，轻量级锁成功率提高
-ConcurrentHashMap
-HashMap的同步实现
-Collections.synchronizedMap(Map<K,V> m)
-返回SynchronizedMap对象
锁分离：
根据功能进行锁分离
ReadWriteLock
读多写少的情况，可以提高性能
锁粗化：
通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽量短，即在使用完公共资源后，应该立即释放锁。
只有这样，等待在这个锁上的其他线程才能尽早的获得资源执行任务。但是，凡事都有一个度，如果对同一个锁不停的进行请求、同步和释放，
其本身也会消耗系统宝贵的资源，反而不利于性能的优化
锁消除：
在即时编译器时，如果发现不可能被共享的对象，则可以消除这些对象的锁操作
无锁：
-锁是悲观的操作
-无锁是乐观的操作
-无锁的一种实现方式
-CAS(Compare And Swap)
-非阻塞的同步
-CAS(V,E,N)
CAS算法的过程是这样：它包含3个参数CAS(V,E,N)。V表示要更新的变量，E表示预期值，N表示新值。仅当V值等于E值时，
才会将V的值设为N，如果V值和E值不同，则说明已经有其他线程做了更新，则当前线程什么都不做。最后，CAS返回当前V的真实值。
CAS操作是抱着乐观的态度进行的，它总是认为自己可以成功完成操作。当多个线程同时使用CAS操作一个变量时，只有一个会胜出，
并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理，
CAS操作即时没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。
-在应用层面判断多线程的干扰，如果有干扰，则通知线程重试
