第二部分：第三章
1.垃圾回收条件
jvm垃圾回收分为俩点，一是对象的内存回收也就是堆内存回收，二是字面量（运行时常量池）和类信息内存回收也就是方法区内存回收。
1.1 对象内存回收（heap）
如何判断对象是否可以回收，市场上有引用计数算法和可达性分析算法两种方法 :
1.1.1 引用计数算法：简单来说就是，一个对象A被引用一次，对象A的引用次数就加一。当对象A的引用次数为0（也就是没有其他地方引用此对象）时可以回收。然而这里存在个问题就是 对象之间互相引用 A->B,B->A时 AB无法回收。不过微软公司的com（componet object model）技术用的就是这个算法，而目前流行的主流的jvm没有选用此算法的。
1.1.2 可达性分析算法：简单来说就是，通过一系统成为Gc Roots的对象为起始点,当冲GC Roots到达不了对象A时，则对象A是不可用的，可回收的。
java语言中，GC Roots包括四种对象：
1.1.2.1 虚拟机栈（栈帧中的本地变量表）中引用的对象
1.1.2.2 本地方法栈中（native方法）引用的对象
1.1.2.3 方法区中类静态属性引用的对象
1.1.2.4 方法区中常量引用的对象
之所以是上面四种，总结为：GC管理的主要区域是Java堆，一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理,因而选择这些区域内的对象作为GC roots
1.2 方法区内存回收：jvm规范不要求虚拟机在方法区实现垃圾收集（因为性价比低，回收一次回收的空间实际情况很小），但是jvm还是有方法区回收的。
1.2.1 字面量回收：如果一个字面量没有被引用就回被回收；
1.2.2 类信息回收：类信息回收需要同时满足3个条件：
1.2.2.1 java堆中不存在此类的实例；
1.2.2.2 加载该类的classloader已经被回收
1.2.2.3 该类对应的java.lang.Class对象没有任何地方引用，也就是说无法再任何地方通过反射访问该类的方法。
1.2.3 其他常量池的东西 暂不清楚。
1.3 四大类型引用：自jdk1.2之后（jdk1.1引用分的种类不够明确），jvm中还有几种类型引用比较特殊；。分别是 强引用、软引用、弱引用、虚引用。
1.3.1 强引用：Object obj=new Object();只要强引用还存在，垃圾收集器永远不会回收被引用的对象。假如obj=null或者obj引用的栈帧出栈（不存在）就会被回收。
1.3.2 软引用：将要发生内存溢出溢出之前，将会把软引用的对象进行回收。SoftReference类实现软引用。
1.3.3 弱引用：只能生存到下一次gc之前。WeakReference类实现弱引用。
1.3.4 虚引用：这个需要注意，虚引用无法用来取得一个对象的实例。虚引用不会对对象的生存时间有任何影响，只是能在这个对象被回收时收到一个系统通知。推荐这篇文章更加了解虚引用：http://www.mamicode.com/info-detail-988201.html。
关于四种引用推荐一篇文章里面有详细例子：http://blog.csdn.net/u011277123/article/details/53908315
1.4 finalize() 对象自救
对象在可达性分析之后还需要进行一些逻辑。哪怕对象在可达性分析之后没有发现与GcRoots的引用链，jvm还需要进行下面几步(需要俩次标记)：
1.4.1 没有发现引用链，进行第一次标记
1.4.2 判断对象是否要执行finalize()方法：当对象没有覆盖finalize()方法或者已经被执行过一次finalize()方法；则此对象不执行finalize()方法，否则进行执行finalize()方法（把对象放在F-Quene队列中）；
jvm自动建立的，低优先级的Finalizer线程去执行放在F-Quene的对象里的finalize()方法。
1.4.3 进行第二次标记，判断对象是否有引用链，没有则回收。
所以如果对象自救（第一次标记没有引用链，第二次标记有引用链），只有在覆盖finalize（）方法激活对象（让对象被引用）。
2.垃圾收集算法：jvm垃圾收集可以分为四种（严格来说是三种）：标记-清除算法；标记-整理算法；复制算法；分代收集算法。
2.1 标记-清除算法：先把可回收内存标记，然后在清除掉；缺点是：会存在内存碎片导致内存泄漏。
2.2 标记-整理算法：先把可回收内存标记，然后让存活的对象都向一端移动，最后清除点端边界以外的内存；缺点：比较标记-清除时间增长；
2.3 复制算法：把内存平分为两份s1,s2；保证只用一个内存区s1，另一个为空s2；把存活的对象复制到为空的那个内存区域s2，然后在清除掉这个区域s1；缺点：内存减半
2.4 分代收集算法：根据jvm特性，年轻代实际每次gc时存活对象较少，故用推荐复制算法；年老代存活对象较多，并且没有其他内存为年老代分配担保（分配担保：举个栗子：年老代为年轻代进行分配担保，当年轻代minor gc内存不足时【比如有个大对象obj1】obj1会放到年老代中；而年老代没有其他空间为其分担了）所以推荐标记-整理算法。
3.hotspot算法实现：暂时未深入理解
4.垃圾收集器：共七中垃圾收集器，分别是serial、parnew、parallel scavenge和cms、serial old、 parallel old、G1；其中serial、parnew、parallel scavenge用于年轻代，cms、serial old、 parallel old用于年老代，g1用于年轻代和年老代。所有收集器都存在stop the world，不过在java发展中 一直在优化停顿时间。
先总结比较这七个收集器：
年轻代：
4.1.Serial:适用于年轻代垃圾回收，复制算法，jdk1.3之前 推荐用于客户端模式(Client)下的虚拟机，属于单线程，无对stop the world优化，属于最老的年轻代垃圾收集器产品；
4.2 ParNew:适用于年轻代垃圾回收，复制算法，jdk1.3发布，推荐用于服务端模式（Server）下的虚拟机，属于多线程，无对stop the world优化，其实就是Serial的多线程版本；是服务端开发的首先；
4.3 Parallel Scavenge：适用于年轻代垃圾回收，复制算法，jdk1.4发布，属于多线程，无对stop the world优化，它是一个可以控制吞吐量的收集器，拥有自适应调节策略；需要注意一点的是，gc停顿时间缩短是牺牲吞吐量和新生代空间来换取的。
stop The World:gc时 需要停止所有线程进行垃圾回收；
吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
自适应调节策略：虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整参数以提高最合适的停顿时间或最大吞吐量。
年老代
4.4 Serial old ：适用于年老代垃圾回收，标记-整理算法，jdk1.5之前，主要用于client下的虚拟机,如果用在server模式下主要有俩个作用：一是jdk1.5以及之前用于与Parallel Scavenger搭配使用，二就是为cms提供后备预案，属于单线程，无stop the world优化。
4.5 Parallel Old：适用于年老代垃圾回收，标记-整理算法，jdk1.6发布，属于多线程，注重于吞吐量控制，是为了Parallel Scavenge定制的；
4.6 CMS: 适用于年老代垃圾回收，标记-清除算法,jdk1.5发布，推荐server模式下，属于多线程，对stop the world有优化，CMS是一种以获取最短回收停顿时间为目标的收集器，也就是优化服务器响应速度。CMS分为4步：其中 初始化标记，重新标记 stop the world
4.6.1 初始标记：仅仅只是标记GcRoots可以直接关联的对象；
4.6.2 并发标记：进行gcroots tracing（也就是 引用链搜索）；优化成并发
4.6.3 重新标记：修正并发标记因用户程序继续运行而导致标记产生变动那一部分对象的标记记录。
4.6.4 并发清除：并发清理标记的对象内存。
4.6.5 CMS缺点：
4.6.5.1 CMS对cpu资源非常敏感，默认启动的回收线程数是（cpu数量+3）/4；垃圾回收线程数量不少于25%的cpu资源，当cpu越大，线程数/cpu总量 越小；但是当cpu小于4个时 显得就不怎么合适了；
4.6.5.2 无法处理浮动垃圾，需要等下一次gc才能处理；并且还需要预留一部分空间提供并发收集时的用户程序运作使用，即启动阈值（-XX:CMSInitiatingOccupancyFraction 阈值百分比）；要是CMS运行期间预留的空间不满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这是虚拟机启动后备预案：临时启用Serial Old，这样一来停顿时间就很长了，所以-XX:CMSInitiatingOccupancyFraction 设置太高容易导致大量“Concurrent Mode Failure”失败，性能反而降低
4.6.5.3 由于用的是标记-清除算法，所以会出现内存碎片；CMS提供-XX:UseCMSCompactAtFullCollection开关参数（默认为开），用于CMS收集器要进行FullGC时进行内存碎片合并整理，-XX:CMSFullGCsBeforeCompaction 用来设置执行多少次不压缩Full GC后跟着来一次带压缩的（默认为0，表示每次进入Full GC都进行碎片压缩）。
年轻代+年老代
4.7 G1：jdk1.7发布，整体看是“标记-整理算法”，从局部（俩个Region之间）上来看是基金“复制”算法实现，也就是说没有内存碎片；
如果应用追求低停顿，那G1现在可以作为一个尝试的选择，如果应该追求吞吐量，G1并不会带来什么特别的好处！！！
5.内存分配策略：共有 4个策略
5.1 对象优先在Eden分配：major gc时经常会伴随至少一次的minor gc，但并非绝对，比如说 Parallel Scavenge就是直接major gc没有伴随minor gc;
5.2 大对象直接进入老年代 -XX：PretenureSizeThreshold设置最大对象，单位B;PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效；Parallel Scavenge收集器不需要设置；如果遇到必须使用此参数的场景，可以考虑ParNew+CMS组合；
5.3 长期存活的对象放入老年代:虚拟机给每个对象定义了一个对象年龄（Age）计数器；gc一次Age+1,当Age大于一定程度（默认为15岁）就会被晋升到老年代；-XX:MaxTenuringThreshold：最大年龄；
5.4 动态对象年龄判定：如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于改年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄；
5.4空间分配担保：jdk6 update 24后，只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行major gc，否则Full GC；
第二部分：第四章
1.jdk的命令行工具简单总结介绍
1.1 jps: 获取虚拟机进程 vmid；jps -v ：显示虚拟机对应启动的参数
1.2 jinfo:获取虚拟机参数值和动态修改部分运行期可改的参数。jinfo [option] pid例如：jinfo -flag PermSize vmid;显示vid对应的虚拟机的方法区大小；jinfo -flag +/- name：添加或删除name属性；
1.3 jmap:java内存影像工具， jmap -heap vmid:显示堆的详细信息，如参数配置，分代状况;jmap -histo vmid:显示堆中对象统计信息，包括类，实例数量，合计容量。
1.4 jstat:虚拟机监控工具，jstat -gccause vmid:输出已使用空间占各自总空间的百分比；
1.5jhat:虚拟机堆转储快照分析工具；jstack：java堆栈跟踪工具；
2.jdk的可视化工具:jConsole和visualVm；其中VisualVM有个BTrace插件值得注意。
2.1 BTrace 动态日志跟踪：可以打印调用堆栈、参数、返回值、性能监视、定位连接泄漏、内存泄漏、解决多线程竞争问题。如生产上遇到问题时需要方法输入参数和返回输出参数，但开发时没有日记记录，平常做法就是补充上日志，然后在重现上线。而BTrace可以在不停止jvm的情况下动态调试代码。（ps:BTrace后续深入研究）
推荐一篇文章：http://huanghaifeng1990.iteye.com/blog/2121419
第二部分：第五章
摘自：https://blog.csdn.net/hupoling/article/details/62887251