个人专题目录

---

2 Java基础

2.1 类加载相关

2.1.1 Java类加载过程

1. 加载

• 加载是类加载的第一个过程，在这个阶段，将完成一下三件事情：
  • 通过一个类的全限定名获取该类的二进制流。
  • 将该二进制流中的静态存储结构转化为方法去运行时数据结构。
  • 在内存中生成该类的 java.lang.Class 对象，作为该类的数据访问入口。

2. 验证
   • 验证的目的是为了确保 Class 文件的字节流中的信息不回危害到虚拟机.在该阶段主要完成以下四钟验证:
     • 文件格式验证：验证字节流是否符合 Class 文件的规范，如主次版本号是否在当前虚拟机范围内，常量池中的常量是否有不被支持的类型。
     • 元数据验证:对字节码描述的信息进行语义分析，如这个类是否有父类，是否集成了不被继承的类等。
     • 字节码验证：是整个验证过程中最复杂的一个阶段，通过验证数据流和控制流的分析，确定程序语义是否正确，主要针对方法体的验证。如：方法中的类型转换是否正确，跳转指令是否正确等。
     • 符号引用验证：这个动作在后面的解析过程中发生，主要是为了确保解析动作能正确执行。
3. 准备
   • 准备阶段是为类的静态变量分配内存并将其初始化为默认值，这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。
4. 解析
   • 该阶段主要完成符号引用到直接引用的转换动作。解析动作并不一定在初始化动作完成之前，也有可能在初始化之后。
5. 初始化
   • 初始化时类加载的最后一步，前面的类加载过程，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的 Java 程序代码。
6. 使用
7. 卸载

2.1.2 谈谈JVM加载Class文件的原理机制？

Java 语言是一种具有动态性的解释型语言，类（Class）只有被加载到 JVM 后才能运行。当运行指定程序时，JVM 会将编译生成的 .class 文件按照需求和一定的规则加载到内存中，并组织成为一个完整的 Java 应用程序。这个加载过程是由类加载器完成，具体来说，就是由 ClassLoader 和它的子类来实现的。类加载器本身也是一个类，其实质是把类文件从硬盘读取到内存中。

类的加载方式分为隐式加载和显示加载。隐式加载指的是程序在使用 new 等方式创建对象时，会隐式地调用类的加载器把对应的类加载到 JVM 中。显示加载指的是通过直接调用 class.forName() 方法来把所需的类加载到 JVM 中。

任何一个工程项目都是由许多类组成的，当程序启动时，只把需要的类加载到 JVM 中，其他类只有被使用到的时候才会被加载，采用这种方法一方面可以加快加载速度，另一方面可以节约程序运行时对内存的开销。此外，在 Java 语言中，每个类或接口都对应一个 .class 文件，这些文件可以被看成是一个个可以被动态加载的单元，因此当只有部分类被修改时，只需要重新编译变化的类即可，而不需要重新编译所有文件，因此加快了编译速度。

在 Java 语言中，类的加载是动态的，它并不会一次性将所有类全部加载后再运行，而是保证程序运行的基础类（例如基类）完全加载到 JVM 中，至于其他类，则在需要的时候才加载。

类加载的主要步骤：

1. 装载。根据查找路径找到相应的 class 文件，然后导入。
2. 链接。链接又可分为 3 个小步：
3. 检查，检查待加载的 class 文件的正确性。
4. 准备，给类中的静态变量分配存储空间。
5. 解析，将符号引用转换为直接引用（这一步可选）
6. 初始化。对静态变量和静态代码块执行初始化工作。

2.1.3 什么是类加载器，类加载器有哪些？

实现通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器。

主要有一下四种类加载器：

1. 启动类加载器（Bootstrap ClassLoader）用来加载 Java 核心类库，无法被 Java 程序直接引用。
2. 扩展类加载器（extensions class loader）：它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。
3. 系统类加载器（system class loader）：它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader() 来获取它。
4. 用户自定义类加载器，通过继承 java.lang.ClassLoader 类的方式实现。

参考：https://www.cnblogs.com/szlbm/p/5504631.html【自定义加载器的使用】

Java类加载机制及自定义加载器 https://www.cnblogs.com/gdpuzxs/p/7044963.html

反射中Class.forName()和ClassLoader.loadClass()的区别：https://www.cnblogs.com/zabulon/p/5826610.html

自定义类加载器

从上面对于java.lang.ClassLoader的loadClass(String name, boolean resolve)方法的解析来看，可以得出以下2个结论：

1、如果不想打破双亲委派模型，那么只需要重写findClass方法即可

2、如果想打破双亲委派模型，那么就重写整个loadClass方法
当然，我们自定义的ClassLoader不想打破双亲委派模型，所以自定义的ClassLoader继承自java.lang.ClassLoader并且只重写findClass方法。

自定义类加载器的使用场景：
1.类字节码加密技术。
2.编写框架代码 , 需要动态加载很多类和资源的时候

2.1.4 类加载器双亲委派模型机制？

当一个类收到了类加载请求时，不会自己先去加载这个类，而是将其委派给父类，由父类去加载，如果此时父类不能加载，反馈给子类，由子类去完成类的加载。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

2.1.5 JVM内存结构

JVM内存结构

2.2 集合线程锁相关

2.2.1 线程的几种可用状态

1. 新建 new。
2. 就绪 放在可运行线程池中，等待被线程调度选中，获取 cpu。
3. 运行 获得了 cpu。
4. 阻塞
   1. 等待阻塞 执行 wait() 。
   2. 同步阻塞 获取对象的同步琐时，同步锁被别的线程占用。
   3. 其他阻塞 执行了 sleep() 或 join() 方法)。
5. 死亡

2.2.2 谈谈 ThreadLocal 是怎么解决并发安全的？

ThreadLocal 这是 Java 提供的一种保存线程私有信息的机制，因为其在整个线程生命周期内有效，所以可以方便地在一个线程关联的不同业务模块之间传递信息，比如事务 ID、Cookie 等上下文相关信息。

ThreadLocal 为每一个线程维护变量的副本，把共享数据的可见范围限制在同一个线程之内，其实现原理是，在 ThreadLocal 类中有一个 Map，用于存储每一个线程的变量的副本。

ThreadLocal 的实现是基于一个所谓的 ThreadLocalMap，在 ThreadLocalMap 中，key为当前ThreadLocal对象，value则是对应线程的变量副本，它的 key 是一个弱引用。
通常弱引用都会和引用队列配合清理机制使用，但是 ThreadLocal 是个例外，它并没有这么做。这意味着，废弃项目的回收依赖于显式地触发，否则就要等待线程结束，进而回收相应 ThreadLocalMap！这就是很多 OOM 的来源，所以通常都会建议，应用一定要自己负责 remove，并且不要和线程池配合，因为 worker 线程往往是不会退出的。

ThreadLocalMap

• 实现线程隔离机制的关键
• 每个Thread内部都有一个ThreadLocal.ThreadLocalMap类型的成员变量，该成员变量用来存储实际的ThreadLocal变量副本。
• 提供了一种用键值对方式存储每一个线程的变量副本的方法，key为当前ThreadLocal对象，value则是对应线程的变量副本
• ThreadLocal实例本身是不存储值，它只是提供了一个在当前线程中找到副本值得key

内存泄漏问题

• key 弱引用 value 强引用，无法回收

2.2.3 ConcurrentHashMap

CAS + Synchronized 来保证并发更新的安全，底层采用数组+链表/红黑树的存储结构

• 根据hash值计算节点插入在table的位置，如果该位置为空，则直接插入，否则插入到链表或者树中

2.2.4 ConcurrentLinkedQueue

基于链接节点的无边界的线程安全队列，采用FIFO原则对元素进行排序，内部采用CAS算法实现

2.2.5 ConcurrentSkipListMap

第三种key-value数据结构：SkipList（跳表）

平衡二叉树结构，Skip list让已排序的数据分布在多层链表中，以0-1随机数决定一个数据的向上攀升与否，通过“空间来换取时间”的一个算法，
在每个节点中增加了向前的指针，在插入、删除、查找时可以忽略一些不可能涉及到的结点，从而提高了效率

2.2.6 CAS 与synchronized 的使用情景

简单的来说CAS 适用于写比较少的情况下（多读场景，冲突一般较少），
synchronized 适用于写比较多的情况下（多写场景，冲突一般较多）

1. 对于资源竞争较少（线程冲突较轻）的情况，使用synchronized 同步锁
   进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗
   cpu 资源；而CAS 基于硬件实现，不需要进入内核，不需要切换线程，
   操作自旋几率较少，因此可以获得更高的性能。
2. 对于资源竞争严重（线程冲突严重）的情况，CAS 自旋的概率会比较
   大，从而浪费更多的CPU 资源，效率低于synchronized。synchronized 的
   底层实现主要依靠 Lock-Free 的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况
   下，可以获得和CAS 类似的性能；而线程冲突严重的情况下，性能远高于CAS
3. Synchronized 是由 JVM 实现的一种实现互斥同步的一种方式， 如果查看被 Synchronized 修饰过的程序块编译后的字节码， 会发现，
   被 Synchronized 修饰过的程序块， 在编译前后被编译器生成了
   monitorenter 和 monitorexi t 两个字节码指令。在虚拟机执行到 monitorenter 指令时， 首先要尝试获取对象的锁：
   如果这个对象没有锁定， 或者当前线程已经拥有了这个对象的锁， 把锁的计数器 +1； 当执行 monitorexi t 指令时将锁计数器 -1； 当计数器
   为 0 时， 锁就被释放了。如果获取对象失败了， 那当前线程就要阻塞等待， 直到对象锁被另外一
   个线程释放为止。Java 中 Synchronize 通过在对象头设置标记， 达到了获取锁和释放
   锁的目的。

clip_image001.gif

对象头：存储对象的hashCode、锁信息或分代年龄或GC标志，类型指针指向对象的类元数据，JVM通过这个指针确定该对象是哪个类的实例等信息。

实例变量：存放类的属性数据信息，包括父类的属性信息

填充数据：由于虚拟机要求对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐

当在对象上加锁时，数据是记录在对象头中。当执行synchronized同步方法或同步代码块时，会在对象头中记录锁标记，锁标记指向的是monitor对象（也称为管程或监视器锁）的起始地址。每个对象都存在着一个 monitor 与之关联，对象与其 monitor 之间的关系有存在多种实现方式，如monitor可以与对象一起创建销毁或当线程试图获取对象锁时自动生成，但当一个 monitor 被某个线程持有后，它便处于锁定状态。

2.2.7 JVM 对 Java 的原生锁做了哪些优化？

一种优化是使用自旋锁，即在把线程进行阻塞操作之前先让线程自旋等待一段时间，可能在等待期间其他线程已经解锁，这时就无需再让线程执行阻塞操作，避免了用户态到内核态的切换。

现代 JDK 中还提供了三种不同的 Monitor 实现，也就是三种不同的锁：
偏向锁（Biased Locking）
轻量级锁
重量级锁,这三种锁使得 JDK 得以优化 Synchronized 的运行，当 JVM 检测到不同的竞争状况时，会自动切换到适合的锁实现，这就是锁的升级、降级。

当没有竞争出现时，默认会使用偏向锁。

JVM 会利用 CAS 操作，在对象头上的 Mark Word 部分设置线程 ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁，因为在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。

如果有另一线程试图锁定某个被偏斜过的对象，JVM 就撤销偏斜锁，切换到轻量级锁实现。

轻量级锁依赖 CAS 操作 Mark Word 来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。

2.2.8 请谈谈 AQS 框架是怎么回事儿？

AQS（AbstractQueuedSynchronizer）就是抽象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，AQS是一个Java提供的底层同步工具类，用一个int类型的变量表示同步状态，并提供了一系列的CAS操作来管理这个同步状态。AQS的主要作用是为Java中的并发同步组件提供统一的底层支持，如常用的ReentrantLock/Semaphore/CountDownLatch等等就是基于AQS实现的，用法是通过继承AQS实现其模版方法，然后将子类作为同步组件的内部类。

1. AQS 在内部定义了一个 volatile int state 变量，表示同步状态：当线程调用 lock 方法时 ，如果 state=0，说明没有任何线程占有共享资源的锁，可以获得锁并将 state=1；如果 state=1，则说明有线程目前正在使用共享变量，其他线程必须加入同步队列进行等待。
2. AQS 通过 Node 内部类构成的一个双向链表结构的同步队列，来完成线程获取锁的排队工作，当有线程获取锁失败后，就被添加到队列末尾。
   1. Node 类是对要访问同步代码的线程的封装，包含了线程本身及其状态叫 waitStatus（有五种不同 取值，分别表示是否被阻塞，是否等待唤醒，是否已经被取消等），每个 Node 结点关联其 prev 结点和 next 结点，方便线程释放锁后快速唤醒下一个在等待的线程，是一个 FIFO 的过程。
   2. Node 类有两个常量，SHARED 和 EXCLUSIVE，分别代表共享模式和独占模式。所谓共享模式是一个锁允许多条线程同时操作（信号量 Semaphore 就是基于 AQS 的共享模式实现的），独占模式是同一个时间段只能有一个线程对共享资源进行操作，多余的请求线程需要排队等待（如 ReentranLock）。
3. AQS 通过内部类 ConditionObject 构建等待队列（可有多个），当 Condition 调用 wait() 方法后，线程将会加入等待队列中，而当
   Condition 调用 signal() 方法后，线程将从等待队列转移动同步队列中进行锁竞争。
4. AQS 和 Condition 各自维护了不同的队列，在使用 Lock 和 Condition 的时候，其实就是两个队列的互相移动。

2.2.9 Synchronized 和 ReentrantLock 的异同

ReentrantLock 是 Lock 的实现类，是一个互斥的同步锁。
从功能角度，ReentrantLock 比 Synchronized 的同步操作更精细（因为可以像普通对象一样使用），甚至实现 Synchronized 没有的高级功能，如：

• 等待可中断：当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，对处理执行时间非常长的同步块很有用。
• 带超时的获取锁尝试：在指定的时间范围内获取锁，如果时间到了仍然无法获取则返回。
• 可以判断是否有线程在排队等待获取锁。
• 可以响应中断请求：与 Synchronized 不同，当获取到锁的线程被中断时，能够响应中断，中断异常将会被抛出，同时锁会被释放。
• 可以实现公平锁。

从锁释放角度，Synchronized 在 JVM 层面上实现的，不但可以通过一些监控工具监控 Synchronized 的锁定，而且在代码执行出现异常时，JVM 会自动释放锁定；但是使用 Lock 则不行，Lock 是通过代
码实现的，要保证锁定一定会被释放，就必须将 unLock() 放到 finally{} 中。

从性能角度，Synchronized 早期实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大。
但是在 Java 6 中对其进行了非常多的改进，在竞争不激烈时，Synchronized 的性能要优于 ReetrantLock；在高竞争情况下，Synchronized 的性能会下降几十倍，但是 ReetrantLock 的性能能维持常态。

2.2.10 ReentrantLock 是如何实现可重入性的？

ReentrantLock 内部自定义了同步器 Sync（Sync 既实现了 AQS，又实现了 AOS，而 AOS 提供了一种互斥锁持有的方式），其实就是加锁的时候通过 CAS 算法，将线程对象放到一个双向链表中，每次获取锁的时候，看下当前维护的那个线程 ID 和当前请求的线程 ID 是否一样，一样就可重入了。

• 可重入锁，是一种递归无阻塞的同步机制
• 比synchronized更强大、灵活的锁机制，可以减少死锁发生的概率，分为公平锁、非公平锁

2.2.11 请谈谈 ReadWriteLock 和 StampedLock和Condition

读写锁基于的原理是多个读操作不需要互斥，如果读锁试图锁定时，写锁是被某个线程持有，读锁将无法获得，而只好等待对方操作结束，这样就可以自动保证不会读取到有争议的数据。

ReadWriteLock 代表了一对锁，下面是一个基于读写锁实现的数据结构，当数据量较大，并发读多、并发写少的时候，能够比纯同步版本凸显出优势。

img img

StampedLock，在提供类似读写锁的同时，还支持优化读模式。优化读基于假设，大多数情况下读操作并不会和写操作冲突，其逻辑是先试着修改，然后通过 validate 方法确认是否进入了写模式，如果没有进入，就成功避免了开销；如果进入，则尝试获取读锁。

• 读写锁，两把锁：共享锁：读锁、排他锁：写锁
• 支持公平性、非公平性，可重入和锁降级
• 锁降级：遵循获取写锁、获取读锁在释放写锁的次序，写锁能够降级成为读锁

Condition

• Lock 提供条件Condition，对线程的等待、唤醒操作更加详细和灵活
• 内部维护一个Condition队列。当前线程调用await()方法，将会以当前线程构造成一个节点（Node），并将节点加入到该队列的尾部