Javaday19（注解、垃圾回收、核心api-String）

一、注解

定义：注解（Annotation），也叫元数据，是一种代码级别的说明。是Java 的JDK1.5版本开始引入的一个特性，与类、接口、枚举是在同一个层次。它可以声明在包、类、属性、方法、局部变量、方法参数等的前面，用来对这些元素进行说明，注释。
作用分类：很多框架技术的新版本中，都可以使用注解替代XML配置文件；

①编写文档：通过代码里标识的元数据生成文档【生成文档doc文档】
② 代码分析：通过代码里标识的元数据对代码进行分析【使用反射】
③编译检查：通过代码里标识的元数据让编译器能够实现基本的编译检查【Override】

二、垃圾回收

运行时的Java实例对象存储在堆内存空间中。当一个对象不再被引用了，它变成可被从堆内存中回收空间。在垃圾回收的过程中，这些对象将被从堆内存中清除，同时它们的空间也就被回收了。
堆内存的空间根据对象的存活时限主要分成了三部分：年轻代、老年代、永久代

年轻代

a-Eden区(所有实例在运行时最初都分配到eden区中)
b-S0 Survivor Space(老一些的对象被从eden区移动到S0区，其实是eden区中的对象经过一次对eden区的Young GC还存活的对象被移动到S0)
c,-S1 Survivor Space(再老一些的对象被从S0区移动到S1区，其实是在Young GC过程中S0区已满，则会将eden区中还存活的对象和S0区中的存活对象移动到S1区中

老年代

经过S0，S1中几轮迭代后还存活的对象被提升到老年代

永久代

包含一些元数据像类、方法等等。永久代空间在JDK8特性中已经被移除

Java垃圾回收是一个自动运行的管理程序运行时使用的内存的进程。通过GC的自动执行JVM将程序员从申请和释放内存的繁重操作中解放出来
作为一个自动执行的进程，程序员不需要在代码中主动初始化GC。Java提供了System.gc()和Runtime.gc()这两个hook来请求JVM调用GC进程
尽管要求系统机制给程序员提供调用GC的机会，但是实际上这是由JVM负责决定的。JVM可以选择拒绝启动GC的请求，因此并不保证这些请求会真的调用垃圾回收。这是JVM基于内存堆空间的Eden区（年轻代）的使用情况做出的决定。
JVM规范将这个选择权利留给了各个JVM的具体实现，因此实际上JVM是如何选择的视不同JVM的实现而定(但应该始终记住的是，不能依赖于这两个方法的调用，它们是不被保证执行的)

Eden Space:当一个实例被创建的时候，它最初被存放在堆内存空间的年轻代的Eden区中
Survivor Space(S0 和S1):作为minor回收周期的一部分，还活着的对象(还有引用指向它)被从eden区中移动到survivor空间S0。同样的，垃圾回收器扫描S0并将活着的实例移动到S1 Old Generation:老年代或者永久代是堆内存的第二个逻辑部分。当垃圾回收器在做minor GC周期中，S1 survivor区中还活着的实例会被提升到老年代中。S1区中不再被引用的对象被标记并清除 Major GC:在Java垃圾回收过程中实例生命周期的最后一个阶段。Major GC在垃圾回收过程中扫描属于Old Generation部分的堆内存。如果实例没有被任何引用关联，它们将被标记、清除;如果它们还被引用关联着，则将继续存留在old generation。
- 无用的对象被标记并回收。垃圾回收器决定这些被标记的实例是在扫描的过程中移出内存还是在另外独立的迁移进程中执行
从上述过程可以看出：生存时限越长的对象，其被垃圾回收处理机制扫描的频率就越低
Fragmentation:一旦实例从堆内存中删除了，它们原来的位置将空出来给以后分配实例使用。显然这些空闲空间很容易在内存空间中产生碎片。为了能够更快地分配实例地址，需要对内存做去碎片化操作。根据不同垃圾回收器的策略，被回收的内存将在回收的过程同时或者在GC另外独立的过程中压缩整合

这四种类型的垃圾回收器都有各自的优点和缺点。最重要的是我们可以选择JVM使用哪种类型的垃圾回收器。我们可以通过传递不同的JVM参数来设置使用哪一个。各个垃圾回收器在不同应用场景下的效率会有很大的差异。因此了解各种不同类型的垃圾回收器以及它们的应用场景是非常重要的
在什么时候使用哪一个取决于应用场景，硬件配置和吞吐量要求

Serial Garbage Collector： 使用-XX:+UseSerialGC JVM参数来开启使用串行垃圾回收器
- 串行垃圾回收器控制所有的应用线程。它是为单线程场景设计的，只使用一个线程来执行垃圾回收工作。它暂停所有应用线程来执行垃圾回收工作的方式不适用于服务器的应用环境。它最适用的是简单的命令行程序

Parallel Garbage Collector：
- 并行垃圾回收器也称作基于吞吐量的回收器。它是JVM的默认垃圾回收器。与Serial不同的是，它使用多个线程来执行垃圾回收工作。和Serial回收器一样，它在执行垃圾回收工作是也需要暂停所有应用线程
CMS Garbage Collector：
- 并发标记清除(Concurrent Mark Sweep,CMS)垃圾回收器，使用多个线程来扫描堆内存并标记可被清除的对象，然后清除标记的对象。CMS垃圾回收器只在下面这两种情形下暂停工作线程：
  - 在老年代中标记引用对象的时候
  - 在做垃圾回收的过程中堆内存中有变化发生
  - 对比与并行垃圾回收器，CMS回收器使用更多的CPU来保证更高的吞吐量。如果我们可以有更多的CPU用来提升性能，那么CMS垃圾回收器是比并行回收器更好的选择

　　　　　　使用-XX:+UseParNewGC JVM参数来开启使用CMS垃圾回收器

G1 Garbage Collector：
- G1垃圾回收器应用于大的堆内存空间。它将堆内存空间划分为不同的区域，对各个区域并行地做回收工作。G1在回收内存空间后还立即对堆空闲空间做整合工作以减少碎片。CMS却是在全部停止(stop the world,STW)时执行内存整合工作。对于不同的区域G1根据垃圾的数量决定优先级
- 使用-XX:UseG1GC JVM参数来开启使用G1垃圾回收器
- 在使用G1垃圾回收器时，开启使用-XX:+UseStringDeduplacaton JVM参数。它会通过把重复的String值移动到同一个char[]数组来优化堆内存占用。这是Java 8 u 20引入的选项

我们知道，GC主要处理的是对象的回收操作，那么什么时候会触发一个对象的回收的呢：
- 对象没有引用
- 作用域发生未捕获异常
- 程序在作用域正常执行完毕
- 程序执行了System.exit()
- 程序发生意外终止（被杀进程等）

在JDK1.2之前，使用的是引用计数器算法，即当类被加载到内存以后，就会产生方法区，堆栈、程序计数器等一系列信息，当创建对象的时候，为这个对象在堆栈空间中分配对象，同时会产生一个引用计数器，同时引用计数器+1，当有新的引用的时候，引用计数器继续+1，而当其中一个引用销毁的时候，引用计数器-1，当引用计数器被减为零的时候，标志着这个对象已经没有引用了，可以回收了

根搜索算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张有向图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点
目前java中可作为GC Root的对象有
- 虚拟机栈中引用的对象（本地变量表）
- 方法区中静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中引用的对象（Native对象）

三、垃圾回收-内存泄漏　　

　　Java语言的一个关键的优势就是它的内存管理机制。你只管创建对象，Java的垃圾回收器帮你分配以及回收内存。然而，实际的情况并没有那么简单，因为内存泄漏在Java应用程序中还是时有发生的

　　内存泄漏的定义：对象已经没有被应用程序使用，但是垃圾回收器没办法移除它们，因为还在被引用着

　　　从刚才的图里面可以看出，里面有被引用对象和未被引用对象。未被引用对象会被垃圾回收器回收，而被引用的对象却不会。

　　　未被引用的对象当然是不再被使用的对象，因为没有对象再引用它。然而无用对象却不全是未被引用对象。其中还有被引用的。就是这种情况导致了内存泄漏

　　上例中，A对象引用B对象，A对象的生命周期（t1-t4）比B对象的生命周期（t2-t3）长的多。当B对象没有被应用程序使用之后，A对象仍然在引用着B对象。这样，垃圾回收器就没办法将B对象从内存中移除，从而导致内存问题，因为如果A引用更多这样的对象，那将有更多的未被引用对象存在，并消耗内存空间

　　B对象也可能会持有许多其他的对象，那这些对象同样也不会被垃圾回收器回收。所有这些没在使用的对象将持续的消耗之前分配的内存空间

下面是几条容易上手的建议，来帮助开发人员防止内存泄漏的发生：

不再使用的对象将指向其的引用置空指向null
特别注意一些像HashMap、ArrayList的集合对象，它们经常会引发内存泄漏。当它们被声明为static时，它们的生命周期就会和应用程序一样长
同样是集合，当原有对象的属性发生改变(hashCode变化)，remove()方法可能会失效，导致内存泄露（后续详细讲解）
特别注意系统中各种事件监听和回调。当一个监听器在使用的时候被注册，但不再使用之后却未被反注册
“如果一个类自己管理内存，那开发人员就得小心内存泄漏问题了。” 通常一些成员变量引用其他对象，初始化的时候需要置空

事实上，对于一些常用API的使用如果不了解其实现方式的话也很容易引起内存泄露
例如，String类常用的截取字串的方法substring()在JDK1.6中如果滥用就会导致比较严重的内存泄露

四、finalize

　　由于Object是Java继承体系的根，因此事实上所有的Java类都具备finalize方法

　　当垃圾回收器确定了一个对象没有任何引用时，其会调用finalize()方法。但是，finalize方法并不保证调用时机，因此也不建议重写finalize()方法

　　如果必须要重写finalize()方法，请记住使用super.finalize()调用父类的清除方法，否则对象清理的过程可能不完整

　　每个对象只能被GC自动调用finalize( )方法一次。如果在finalize( )方法执行时产生异常（exception），则该对象仍可以被垃圾收集器收集

　　Java语言允许程序员为任何方法添加finalize( )方法，该方法会在垃圾收集器交换回收对象之前被调用。但不要过分依赖该方法对系统资源进行回收和再利用，因为该方法调用后的执行结果是不可预知的

　　当finalize( )方法尚未被调用时，System. runFinalization( )方法可以用来调用finalize( )方法，并实现相同的效果，对无用对象进行垃圾收集

　　还有一个理由让我们需要更加谨慎对待finalize方法，那就是它其实有可能会阻断垃圾回收器对本对象的回收，我们称为对象复活，造成逻辑混乱和内存泄露

　　垃圾收集器跟踪每一个对象，收集那些不可到达的对象（即该对象没有被程序的任何“活的部分”所调用），回收其占有的内存空间。但在进行垃圾回收的时候，垃圾回收器会调用finalize( )方法，通过让其他对象知道它的存在，而使不可到达的对象再次“复活"为可到达的对象

　　既然每个对象只能调用一次finalize( )方法，所以每个对象也只可能“复活"一次

　　强引用：

　　　　以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用:

　　　　　　ClassName object = new ClassName();

　　　　如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题

　　软引用：

　　　如果一个对象只具有软引用，那就类似于可有可物的生活用品。如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存

　　　　String str=new String("abc");

　　　　SoftReference<String> softRef=new SoftReference<String>(str);

　　弱引用：

　　　　如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象

　　　　String str=new String("abc");

　　　　WeakReference<String> weakRef=new WeakReference<String>(str);

　　虚引用：虚引用示例：

　　顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收

　　虚引用主要用来跟踪对象被垃圾回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。程序如果发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动

　　String str = new String("abc");

　　ReferenceQueue<String> queue = new ReferenceQueue<String>();

　　PhantomReference<String> phantomRef = new PhantomReference<String>(str, queue);

由于虚引用的特点，绑定应用队列后是finalize()方法的理想替代品，一旦虚引用被加入引用队列，就没有任何办法获取虚引用指向的对象，因此不存在对象复活的隐患
正如之前说的，软引用、弱引用、虚引用均可以和一个引用队列绑定使用
ReferenceQueue是作为 JVM GC与上层Reference对象管理之间的一个消息传递方式，它使得我们可以对所监听的对象引用可达发生变化时做一些处理
我们希望当一个对象被gc掉的时候通知用户线程，进行额外的处理时，就需要使用引用队列了。ReferenceQueue即这样的一个对象，当一个obj被gc掉之后，其相应的引用对象（软引用、弱引用、虚引用），即ref对象会被放入queue中。我们可以从queue中获取到相应的对象信息，同时进行额外的处理。比如反向操作，数据清理

实现了一个队列的入队(enqueue)和出队(poll还有remove)操作，内部元素就是泛型的Reference，并且Queue的实现，是由Reference自身的链表结构所实现的
引用队列的入队操作是由垃圾回收器完成的，当其发现回收的对象具备软引用、弱引用或虚引用时，会自动将对象的引用对象入队
我们只需要在必要时执行出队操作即可监控到有哪些对象被回收并执行相关的资源操作