强引用、软引用、弱引用、虚引用是什么，有什么区别？
强引用：在程序中普遍存在的引用赋值，类似Object obj = new Object()这种引用关系。只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。
软引用：如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。
//软引用
SoftReference<String> softRef = new SoftReference<String>(str);
复制代码弱引用：在进行垃圾回收时，不管当前内存空间足够与否，都会回收只具有弱引用的对象。
//弱引用
WeakReference<String> weakRef = new WeakReference<String>(str);
复制代码虚引用：虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。虚引用主要是为了能在对象被收集器回收时收到一个系统通知。
Minor GC 和 Full GC的区别？
- Minor GC：回收新生代，因为新生代对象存活时间很短，因此
Minor GC会频繁执行，执行的速度一般也会比较快。 - Full GC：回收老年代和新生代，老年代的对象存活时间长，因此
Full GC很少执行，执行速度会比Minor GC慢很多。
内存的分配策略？
对象优先在 Eden 分配
大多数情况下，对象在新生代 Eden 上分配，当 Eden 空间不够时，触发 Minor GC。
大对象直接进入老年代
大对象是指需要连续内存空间的对象，最典型的大对象有长字符串和大数组。可以设置JVM参数 -XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配。
长期存活的对象进入老年代
通过参数 -XX:MaxTenuringThreshold 可以设置对象进入老年代的年龄阈值。对象在Survivor区每经过一次 Minor GC，年龄就增加 1 岁，当它的年龄增加到一定程度，就会被晋升到老年代中。
动态对象年龄判定
并非对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需达到 MaxTenuringThreshold 年龄阈值。
空间分配担保
在发生 Minor GC 之前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果条件成立的话，那么 Minor GC 是安全的。如果不成立的话虚拟机会查看 HandlePromotionFailure 的值是否允许担保失败。如果允许，那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次 Minor GC；如果小于，或者 HandlePromotionFailure 的值为不允许担保失败，那么就要进行一次 Full GC。
Full GC 的触发条件？
对于 Minor GC，其触发条件比较简单，当 Eden 空间满时，就将触发一次 Minor GC。而 Full GC 触发条件相对复杂，有以下情况会发生 full GC：
调用 System.gc()
只是建议虚拟机执行 Full GC，但是虚拟机不一定真正去执行。不建议使用这种方式，而是让虚拟机管理内存。
老年代空间不足
老年代空间不足的常见场景为前文所讲的大对象直接进入老年代、长期存活的对象进入老年代等。为了避免以上原因引起的 Full GC，应当尽量不要创建过大的对象以及数组。除此之外，可以通过 -Xmn 参数调大新生代的大小，让对象尽量在新生代被回收掉，不进入老年代。还可以通过 -XX:MaxTenuringThreshold 调大对象进入老年代的年龄，让对象在新生代多存活一段时间。
空间分配担保失败
使用复制算法的 Minor GC 需要老年代的内存空间作担保，如果担保失败会执行一次 Full GC。
JDK 1.7 及以前的永久代空间不足
在 JDK 1.7 及以前，HotSpot 虚拟机中的方法区是用永久代实现的，永久代中存放的为一些 Class 的信息、常量、静态变量等数据。当系统中要加载的类、反射的类和调用的方法较多时，永久代可能会被占满，在未配置为采用 CMS GC 的情况下也会执行 Full GC。如果经过 Full GC 仍然回收不了，那么虚拟机会抛出 java.lang.OutOfMemoryError。
垃圾回收算法有哪些？
垃圾回收算法有四种，分别是标记清除法、标记整理法、复制算法、分代收集算法。
标记清除算法
首先利用可达性去遍历内存，把存活对象和垃圾对象进行标记。标记结束后统一将所有标记的对象回收掉。这种垃圾回收算法效率较低，并且会产生大量不连续的空间碎片。
复制清除算法
半区复制，用于新生代垃圾回收。将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。
特点：实现简单，运行高效，但可用内存缩小为了原来的一半，浪费空间。
标记整理算法
根据老年代的特点提出的一种标记算法，标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存。
分类收集算法
根据各个年代的特点采用最适当的收集算法。
一般将堆分为新生代和老年代。
- 新生代使用复制算法
- 老年代使用标记清除算法或者标记整理算法
在新生代中，每次垃圾收集时都有大批对象死去，只有少量存活，使用复制算法比较合适，只需要付出少量存活对象的复制成本就可以完成收集。老年代对象存活率高，适合使用标记-清理或者标记-整理算法进行垃圾回收。
有哪些垃圾回收器？
垃圾回收器主要分为以下几种：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1。
这7种垃圾收集器的特点：
| 收集器 | 串行、并行or并发 | 新生代/老年代 | 算法 | 目标 | 适用场景 |
|---|---|---|---|---|---|
| Serial | 串行 | 新生代 | 复制算法 | 响应速度优先 | 单CPU环境下的Client模式 |
| ParNew | 并行 | 新生代 | 复制算法 | 响应速度优先 | 多CPU环境时在Server模式下与CMS配合 |
| Parallel Scavenge | 并行 | 新生代 | 复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
| Serial Old | 串行 | 老年代 | 标记-整理 | 响应速度优先 | 单CPU环境下的Client模式、CMS的后备预案 |
| Parallel Old | 并行 | 老年代 | 标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
| CMS | 并发 | 老年代 | 标记-清除 | 响应速度优先 | 集中在互联网站或B/S系统服务端上的Java应用 |
| G1 | 并发 | both | 标记-整理+复制算法 | 响应速度优先 | 面向服务端应用，将来替换CMS |
Serial 收集器
单线程收集器，使用一个垃圾收集线程去进行垃圾回收，在进行垃圾回收的时候必须暂停其他所有的工作线程（ Stop The World ），直到它收集结束。
特点：简单高效；内存消耗小；没有线程交互的开销，单线程收集效率高；需暂停所有的工作线程，用户体验不好。
ParNew 收集器
Serial收集器的多线程版本，除了使用多线程进行垃圾收集外，其他行为、参数与 Serial 收集器基本一致。
Parallel Scavenge 收集器
新生代收集器，基于复制清除算法实现的收集器。特点是吞吐量优先，能够并行收集的多线程收集器，允许多个垃圾回收线程同时运行，降低垃圾收集时间，提高吞吐量。所谓吞吐量就是 CPU 中用于运行用户代码的时间与 CPU 总消耗时间的比值（吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间））。Parallel Scavenge 收集器关注点是吞吐量，高效率的利用 CPU 资源。CMS 垃圾收集器关注点更多的是用户线程的停顿时间。
Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。
-XX：MaxGCPauseMillis参数的值是一个大于0的毫秒数，收集器将尽量保证内存回收花费的时间不超过用户设定值。-XX：GCTimeRatio参数的值大于0小于100，即垃圾收集时间占总时间的比率，相当于吞吐量的倒数。
Serial Old 收集器
Serial 收集器的老年代版本，单线程收集器，使用标记整理算法。
Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。多线程垃圾收集，使用标记整理算法。
CMS 收集器
Concurrent Mark Sweep ，并发标记清除，追求获取最短停顿时间，实现了让垃圾收集线程与用户线程基本上同时工作。
CMS 垃圾回收基于标记清除算法实现，整个过程分为四个步骤：
- 初始标记： 暂停所有用户线程（
Stop The World），记录直接与GC Roots直接相连的对象 。 - 并发标记：从
GC Roots开始对堆中对象进行可达性分析，找出存活对象，耗时较长，但是不需要停顿用户线程。 - 重新标记： 在并发标记期间对象的引用关系可能会变化，需要重新进行标记。此阶段也会暂停所有用户线程。
- 并发清除：清除标记对象，这个阶段也是可以与用户线程同时并发的。
在整个过程中，耗时最长的是并发标记和并发清除阶段，这两个阶段垃圾收集线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
优点：并发收集，停顿时间短。
缺点：
- 标记清除算法导致收集结束有大量空间碎片。
- 产生浮动垃圾，在并发清理阶段用户线程还在运行，会不断有新的垃圾产生，这一部分垃圾出现在标记过程之后，
CMS无法在当次收集中回收它们，只好等到下一次垃圾回收再处理；
G1收集器
G1垃圾收集器的目标是在不同应用场景中追求高吞吐量和低停顿之间的最佳平衡。
G1将整个堆分成相同大小的分区（Region），有四种不同类型的分区：Eden、Survivor、Old和Humongous。分区的大小取值范围为 1M 到 32M，都是2的幂次方。分区大小可以通过-XX:G1HeapRegionSize参数指定。Humongous区域用于存储大对象。G1规定只要大小超过了一个分区容量一半的对象就认为是大对象。
G1 收集器对各个分区回收所获得的空间大小和回收所需时间的经验值进行排序，得到一个优先级列表，每次根据用户设置的最大回收停顿时间，优先回收价值最大的分区。
特点：可以由用户指定期望的垃圾收集停顿时间。
G1 收集器的回收过程分为以下几个步骤：
- 初始标记。暂停所有其他线程，记录直接与
GC Roots直接相连的对象，耗时较短 。 - 并发标记。从
GC Roots开始对堆中对象进行可达性分析，找出要回收的对象，耗时较长，不过可以和用户程序并发执行。 - 最终标记。需对其他线程做短暂的暂停，用于处理并发标记阶段对象引用出现变动的区域。
- 筛选回收。对各个分区的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，然后把决定回收的分区的存活对象复制到空的分区中，再清理掉整个旧的分区的全部空间。这里的操作涉及存活对象的移动，会暂停用户线程，由多条收集器线程并行完成。
Java学习视频
Java基础：
Java300集，Java必备优质视频_手把手图解学习Java，让学习成为一种享受
Java项目：
【Java游戏项目】1小时教你用Java语言做经典扫雷游戏_手把手教你开发游戏
【Java毕业设计】OA办公系统项目实战_OA员工管理系统项目_java开发