java-基础知识

Thread.currentThread.setContextClassloader(mysql驱动)

文件格式验证（Class 文件格式检查）

元数据验证（字节码语义检查）

字节码验证（程序语义检查）

符号引用验证（类的正确性检查）

为类的静态变量分配内存，并将其初始化为默认值
数据类型默认的零值(如0、0L、null、false等)
final 修饰直接初始化为对应的值

虚拟机将常量池内的符号引用替换为直接引用的过程

通过new关键字会导致类的初始化

访问类的静态变量，包括读取和更新会导致类的初始化

访问类的静态方法，也会导致类初始化

初始化子类会导致父类被初始化

对某个类进行反射操作。会导致类被初始化

启动类，就是执行main函数所在的类会导致该类被初始化

用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁等。
这部分数据长度在32位机器和64位机器虚拟机中分别为4字节和8字节
（64位的JVM为了节约内存可以使用选项+UseCompressedOops开启指针压缩，开启该选项后，占用字节数降为4字节）；

即对象指向它的类元数据（保存在方法区）的指针，虚拟机通过这个指针来确定
这个对象属于哪个类的实例，指针占用4个字节（64位机器占8个字节）；

只有数组对象才有：如果是 Java 数组，对象头必须有一块用于记录数组长度的数据，用4个字节int来记录数组长度；

public class ObjectHeaderTest {
    public static void main(String[] args) {
        System.out.println("=========打印Object对象的大小========");
        ClassLayout layout = ClassLayout.parseInstance(new Object());
        System.out.println(layout.toPrintable());
        System.out.println("========打印数组对象的大小=========");
        ClassLayout layout1 = ClassLayout.parseInstance(new int[]{});
        System.out.println(layout1.toPrintable());
        System.out.println("========打印有成员变量的对象大小=========");
        ClassLayout layout2 = ClassLayout.parseInstance(new ArtisanTest());
        System.out.println(layout2.toPrintable());
    }

    /**
     * ‐XX:+UseCompressedOops 表示开启压缩普通对象指针
     * ‐XX:+UseCompressedClassPointers 表示开启压缩类指针
     *
     */
    public static class ArtisanTest {

        int id;        //4B
        String name;   //4B
        byte b;        //1B
        Object o;      //4B
    }
}

分配方法

安全问题

父类的实例成员变量声明和实例初始化块（按照声明顺序）
父类构造方法
子类的实例成员变量声明和实例初始化块（按照声明顺序）
子类的构造方法

JDK中的ThreadLocalMap又做了一次精彩的表演，它没有继承java.util.Map类，而是自己实现了一套专门用来定时清理无效资源的字典结构。其内部存储实体结构Entry<ThreadLocal, T>继承自java.lan.ref.WeakReference，这样当ThreadLocal不再被引用时，因为弱引用机制原因，当jvm发现内存不足时，会自动回收弱引用指向的实例内存，即其线程内部的ThreadLocalMap会释放其对ThreadLocal的引用从而让jvm回收ThreadLocal对象。这里是重点强调下，是回收对ThreadLocal对象，而非整个Entry，所以线程变量中的值T对象还是在内存中存在的，所以内存泄漏的问题还没有完全解决。 

代表有序、可重复的集合

代表无序、不可重复的集合

代表一种队列集合实现

hashmap

ConcurrentHashMap

volatile

NEW

RUNNABLE

BLOCKED

WAITING

TIMED_WAITING

TERMINATED

  Thread thread1 =  new Thread(){
            @Override
            public void run() {
                System.out.println("run2");
            }
        };

Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("run");
            }
        });

class MyCallable implements Callable<String> {
    public String call() {
        return "Thread is running...";
    }
}
        Callable<String> callable = new MyCallable();
       
        // 创建FutureTask对象，用于包装Callable对象
        FutureTask<String> futureTask = new FutureTask<>(callable);
       
        // 创建线程并启动
        Thread thread = new Thread(futureTask);
        thread.start();
       
        try {
            // 获取线程执行结果
            String result = futureTask.get();
            System.out.println(result);
        } catch (Exception e) {
            e.printStackTrace();
        }
 

Executors.newFixedThreadPool(int nThreads)
固定大小线程池

Executors.newCachedThreadPool()
缓存线程池

Executors.newSingleThreadExecutor()
单例线程池

Executors.newScheduledThreadPool(int corePoolSize)
调度线程池

参数

异常处理

线程池状态

Runnable接口和Callable接口的区别
Runnable和Callable都是用于创建线程任务的接口，它们之间的主要区别在于以下几点：
返回值
Runnable接口的run()方法没有返回值，因此线程任务无法返回执行结果。
Callable接口的call()方法可以返回执行结果，并且可以抛出受检查的异常。
异常处理
Runnable接口的run()方法不能抛出受检查的异常，只能抛出非受检查的RuntimeException。
Callable接口的call()方法可以抛出任何类型的异常，包括受检查的异常。
兼容性
Callable接口是在Java 5中引入的新接口，而Runnable接口是在Java 1.0中就存在的。
Callable接口提供了更多的灵活性和功能，但Runnable接口仍然是使用较多的接口之一，因为它的简单性和兼容性。
并发集合
Callable接口通常与ExecutorService和Future配合使用，以支持异步任务执行和获取结果。
Runnable接口通常与Thread类或者Executor框架一起使用，用于执行简单的线程任务。
总的来说，如果需要线程执行任务并返回结果，以及处理受检查的异常，那么可以使用Callable接口；如果只是需要执行简单的线程任务，而不需要返回结果或处理异常，那么可以使用Runnable接口。

submit()/execute()：执行线程池
shutdown()/shutdownNow()：终止线程池
isShutdown()：判断线程是否终止
getActiveCount()：正在运行的线程数
getCorePoolSize()：获取核心线程数
getMaximumPoolSize()：获取最大线程数
getQueue()：获取线程池中的任务队列
allowCoreThreadTimeOut(boolean)：设置空闲时是否回收核心线程 

线程池中核心线程数量大小怎么设置？
CPU密集型任务
尽量使用较小的线程池，一般为CPU核心数+1。 因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，会造成CPU过度切换。
IO密集型任务
可以使用稍大的线程池，一般为2*CPU核心数。 IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候有其他线程去处理别的任务，充分利用CPU时间。
混合型任务
可以将任务分成IO密集型和CPU密集型任务，然后分别用不同的线程池去处理。 只要分完之后两个任务的执行时间相差不大，那么就会比串行执行来的高效。因为如果划分之后两个任务执行时间有数据级的差距，那么拆分没有意义。因为先执行完的任务就要等后执行完的任务，最终的时间仍然取决于后执行完的任务，而且还要加上任务拆分与合并的开销，得不偿失。
以上只是理论值，实际项目中建议在本地或者测试环境进行多次调优，找到相对理想的值大小。

什么是阻塞队列？说说常用的阻塞队列有哪些？
阻塞队列 BlockingQueue 继承 Queue，是我们熟悉的基本数据结构队列的一种特殊类型。
当从阻塞队列中获取数据时，如果队列为空，则等待直到队列有元素存入。当向阻塞队列中存入元素时，如果队列已满，则等待直到队列中有元素被移除。提供 offer()、put()、take()、poll() 等常用方法。

JDK 提供的阻塞队列的实现有以下几种：
1）ArrayBlockingQueue：由数组实现的有界阻塞队列，该队列按照 FIFO 对元素进行排序。维护两个整形变量，标识队列头尾在数组中的位置，在生产者放入和消费者获取数据共用一个锁对象，意味着两者无法真正的并行运行，性能较低。
2）LinkedBlockingQueue：由链表组成的有界阻塞队列，如果不指定大小，默认使用 Integer.MAX_VALUE 作为队列大小，该队列按照 FIFO 对元素进行排序，对生产者和消费者分别维护了独立的锁来控制数据同步，意味着该队列有着更高的并发性能。
3）SynchronousQueue：不存储元素的阻塞队列，无容量，可以设置公平或非公平模式，插入操作必须等待获取操作移除元素，反之亦然。
4）PriorityBlockingQueue：支持优先级排序的无界阻塞队列，默认情况下根据自然序排序，也可以指定 Comparator。
5）DelayQueue：支持延时获取元素的无界阻塞队列，创建元素时可以指定多久之后才能从队列中获取元素，常用于缓存系统或定时任务调度系统。
6）LinkedTransferQueue：一个由链表结构组成的无界阻塞队列，与LinkedBlockingQueue相比多了transfer和tryTranfer方法，该方法在有消费者等待接收元素时会立即将元素传递给消费者。
7）LinkedBlockingDeque：一个由链表结构组成的双端阻塞队列，可以从队列的两端插入和删除元素。

你们线程池是咋监控的？
因为线程池的运行相对而言是个黑盒，它的运行我们感知不到，该问题主要考察怎么感知线程池的运行情况。
可以这样回答：
我们自己对线程池 ThreadPoolExecutor 做了一些增强，做了一个线程池管理框架。主要功能有监控告警、动态调参。主要利用了 ThreadPoolExecutor 类提供
的一些 set、get方法以及一些钩子函数。
动态调参是基于配置中心实现的，核心参数配置在配置中心，可以随时调整、实时生效，利用了线程池提供的 set 方法。
监控，主要就是利用线程池提供的一些 get 方法来获取一些指标数据，然后采集数据上报到监控系统进行大盘展示。也提供了 Endpoint 实时查看线程池指标数据。
同时定义了5种告警规则。
线程池活跃度告警。活跃度 = activeCount / maximumPoolSize，当活跃度达到配置的阈值时，会进行事前告警。
队列容量告警。容量使用率 = queueSize / queueCapacity，当队列容量达到配置的阈值时，会进行事前告警。
拒绝策略告警。当触发拒绝策略时，会进行告警。
任务执行超时告警。重写 ThreadPoolExecutor 的 afterExecute() 和 beforeExecute()，根据当前时间和开始时间的差值算出任务执行时长，超过配置的阈值会触发告警。
任务排队超时告警。重写 ThreadPoolExecutor 的 beforeExecute()，记录提交任务时时间，根据当前时间和提交时间的差值算出任务排队时长，超过配置的阈值会触发告警
通过监控+告警可以让我们及时感知到我们业务线程池的执行负载情况，第一时间做出调整，防止事故的发生。

你在使用线程池的过程中遇到过哪些坑或者需要注意的地方？
这个问题其实也是在考察你对一些细节的掌握程度，就全甩锅给年轻刚毕业没经验的自己就行。可以适当多说些，也证明自己对线程池有着丰富的使用经验。
1）OOM 问题。刚开始使用线程都是通过 Executors 创建的，前面说了，这种方式创建的线程池会有发生 OOM 的风险。
2）任务执行异常丢失问题。可以通过下述4种方式解决
在任务代码中增加 try、catch 异常处理
如果使用的 Future 方式，则可通过 Future 对象的 get 方法接收抛出的异常
为工作线程设置
setUncaughtExceptionHandler，在 uncaughtException 方法中处理异常
可以重写 afterExecute(Runnable r, Throwable t) 方法，拿到异常 t
3）共享线程池问题。整个服务共享一个全局线程池，导致任务相互影响，耗时长的任务占满资源，短耗时任务得不到执行。同时父子线程间会导致死锁的发生，今儿导致 OOM
4）跟 ThreadLocal 配合使用，导致脏数据问题。我们知道 Tomcat 利用线程池来处理收到的请求，会复用线程，如果我们代码中用到了 ThreadLocal，在请求处理完后没有去 remove，那每个请求就有可能获取到之前请求遗留的脏值。
5）ThreadLocal 在线程池场景下会失效，可以考虑用阿里开源的 Ttl 来解决

execute和submit的区别
提交任务的类型：
execute和submit都属于线程池的方法，execute只能提交Runnable类型的任务
submit既能提交Runnable类型任务也能提交Callable类型任务。
异常：
execute会直接抛出任务执行时的异常，可以用try、catch来捕获，和普通线程的处理方式完全一致
submit会吃掉异常，可通过Future的get方法将任务执行时的异常重新抛出。
返回值：
execute()没有返回值
submit有返回值，所以需要返回值的时候必须使用submit
注：execute 执行futureTask 可以通过futureTask.get 拿到返回值

本地方法（native method），它会调用操作系统提供的功能来使当前线程休眠指定的毫秒数。

当调用 sleep() 方法时，当前线程会进入 TIMED_WAITING 状态，直到指定的时间到达或者被中断（InterruptedException）。
不会释放锁

join()方法要做的事就是，当有新的线程加入时，主线程会进入等待状态，一直到调用join()方法的线程执行结束为止。
底层isAlive Thread.wait实现，循环

yield() 方法尝试减少当前线程的运行时间片，从而给予同优先级的其他线程执行的机会。当一个线程调用 yield() 方法时，它表明自己愿意暂停执行，让出CPU给具有相同优先级的线程。然而，这种行为并不是强制性的，取决于操作系统的线程调度器是否接受这个建议

interrupt()是给线程设置中断标志:底层interrupt0；（设置线程中断后，线程内调用 wait()、join()、slepp() 方法中的一种，都会抛出 InterruptedException 异常，且中断标志位被清除，重新设置为 false；当线程被阻塞，比如调用了上述三个方法之一，那么此时调用它的 interrupt() 方法，也会产生一个 InterruptedException 异常。因为没有占有 CPU 的线程是无法给自己设置中断状态位置的；阻塞方法park响应中断，即t3被LockSupport.park()阻塞，然后主线程调用t3.interrupt()，park()方法就响应中断，结束阻塞，并且不会抛出异常，t3线程继续向下执行，同时不会清除中断标记位，仍为true。）
interrupted()是检测中断并清除中断状态（interrupted()作用于当前线程，要在线程内使用，是个坑，已经被废弃）；
isInterrupted()只检测中断。 interrupt()和isInterrupted()作用于此线程，即代码中调用此方法的实例所代表的线程。 

已被废弃
checkAccess stop0 

互斥条件

持有并等待

不可抢占条件

循环等待

如避免嵌套锁、使用可重入锁、资源分配策略等
锁顺序、锁超时

所谓原子性就是指一个操作或者多个操作，要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。被synchronized修饰的类或对象的所有操作都是原子的，因为在执行操作之前必须先获得类或对象的锁，直到执行完才能释放。

可见性是指多个线程访问一个资源时，该资源的状态、值信息等对于其他线程都是可见的。
synchronized和volatile都具有可见性，其中synchronized对一个类或对象加锁时，一个线程如果要访问该类或对象必须先获得它的锁，而这个锁的状态对于其他任何线程都是可见的，并且在释放锁之前会将对变量的修改刷新到共享内存当中，保证资源变量的可见性。

有序性值程序执行的顺序按照代码先后执行。 synchronized和volatile都具有有序性，Java允许编译器和处理器对指令进行重排，但是指令重排并不会影响单线程的顺序，它影响的是多线程并发执行的顺序性。synchronized保证了每个时刻都只有一个线程访问同步代码块，也就确定了线程执行同步代码块是分先后顺序的，保证了有序性。

在 Java 虚拟机(HotSpot)中，Monitor 是基于 C++实现的，由ObjectMonitor实现的。每个对象中都内置了一个 ObjectMonitor对象。
另外，wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

锁定方法作用于当前对象实例加锁，进入同步代码前要获得 当前对象实例的锁
synchronized(this|object) 表示进入同步代码库前要获得给定对象的锁。

也就是给当前类加锁，会作用于类的所有对象实例 ，进入同步代码前要获得 当前 class 的锁。
synchronized(类.class) 表示进入同步代码前要获得 当前 class 的锁

指定加锁对象，对给定对象/类加锁。

偏向锁

轻量锁

重量级锁

锁消除

锁膨胀

线程会放到等待池_WaitSet当中，等待池的线程是不会去竞争同步锁。只有调用了notify（）或notifyAll()后等待池的线程才会(_EntryList)开始去竞争锁

（1）必须在synchronized 修饰的同步代码块中调用
（2）会释放cpu资源和释放同步锁（类锁和对象锁）
（3）调用wait（）后必须调用notify（）或notifyAll（）后线程才会从等待池进入到锁池，当我们的线程竞争得到同步锁后就会重新进入绪状态等待cpu资源分配
（4）是Object类的方法

线程会放到等待池_WaitSet当中, 如果经过long(毫秒)时间后没有收到notify或者notifyAll的通知，自动从等待队列转入锁池队列 _EntryList

随机唤醒一个处在等待状态的线程。

唤醒所有处在等待状态的线程。

传统的并发控制手段，如使用synchronized关键字或者ReentrantLock等互斥锁机制，虽然能够有效防止资源的竞争冲突，但也可能带来额外的性能开销，如上下文切换、锁竞争导致的线程阻塞等。而此时就出现了一种乐观锁的策略，以其非阻塞、轻量级的特点，在某些场合下能更好地提升并发性能，其中最为关键的技术便是Compare And Swap（简称CAS）。
CAS是一种无锁算法，它在硬件级别提供了原子性的条件更新操作，允许线程在不加锁的情况下实现对共享变量的修改。
 CAS是原子指令，一种基于锁的操作，而且是乐观锁，又称无锁机制。CAS操作包含三个基本操作数：内存位置、期望值和新值。

在执行CAS操作时，计算机会检查内存位置当前是否存放着期望值，如果是，则将内存位置的值更新为新值；若不是，则不做任何修改，保持原有值不变，并返回当前内存位置的实际值。
CAS操作通过一条CPU的原子指令，保证了比较和更新的原子性。在执行CAS操作时，CPU会判断当前系统是否为多核系统，如果是，则会给总线加锁，确保只有一个线程能够执行CAS操作。这种独占式的原子性实现方式，比起使用synchronized等重量级锁，具有更短的排他时间，因此在多线程情况下性能更佳。
 

在Java中，CAS机制被封装在jdk.internal.misc.Unsafe类中，尽管这个类并不建议在普通应用程序中直接使用，但它是构建更高层次并发工具的基础，例如java.util.concurrent.atomic包下的原子类如AtomicInteger、AtomicLong等。这些原子类通过JNI调用底层硬件提供的CAS指令，从而在Java层面上实现了无锁并发操作。
Java的标准库中，特别是jdk.internal.misc.Unsafe类提供了一系列compareAndSwapXXX方法，这些方法底层确实是通过C++编写的内联汇编来调用对应CPU架构的cmpxchg指令，从而实现原子性的比较和交换操作。 
Unsafe中的compareAndSetInt使用了@HotSpotIntrinsicCandidate注解修饰，@HotSpotIntrinsicCandidate注解是Java HotSpot虚拟机（JVM）的一个特性注解，它表明标注的方法有可能会被HotSpot JVM识别为“内联候选”，当JVM发现有方法被标记为内联候选时，会尝试利用底层硬件提供的原子指令（比如cmpxchg指令）直接替换掉原本的Java方法调用，从而在运行时获得更好的性能。 
CAS机制中使用了3个基本操作数：内存地址V，旧的预期值A，要修改的新值B。

基本原子类

数组原子类

引用原子类

字段更新原子类

线程安全计数器：由于CAS操作是原子性的，因此CAS可以用来实现一个线程安全的计数器；
队列： 在并发编程中，队列经常用于多线程之间的数据交换。使用CAS可以实现无锁的非阻塞队列（Lock-Free Queue）；
数据库并发控制： 乐观锁就是通过CAS实现的，它可以在数据库并发控制中保证多个事务同时访问同一数据时的一致性；
自旋锁： 自旋锁是一种非阻塞锁，当线程尝试获取锁时，如果锁已经被其他线程占用，则线程不会进入休眠，而是一直在自旋等待锁的释放。自旋锁的实现可以使用CAS操作；
线程池： 在多线程编程中，线程池可以提高线程的使用效率。使用CAS操作可以避免对线程池的加锁，从而提高线程池的并发性能。

ABA问题

只能保证一个共享变量的原子操作

循环时间长开销大

CAS是一种无锁算法，它在硬件级别提供了原子性的条件更新操作，允许线程在不加锁的情况下实现对共享变量的修改。
CAS是原子指令，一种基于锁的操作，而且是乐观锁，又称无锁机制

同步原语

线程调度

Lock的实现原理可以简单概括为：通过同步原语来实现线程的加锁和释放锁操作，并通过线程调度来保证线程的正确执行顺序。在具体的Lock实现中，可能会采用不同的同步原语和线程调度机制，以满足不同的需求和性能要求。例如，常用的Lock实现类ReentrantLock就是基于AQS（AbstractQueuedSynchronizer）同步器和Condition条件队列来实现的。
LockSupport.park LockSupport.unpark 

如何保证互斥性--共享资源state 0-无锁 1-有锁

被拒绝访问的线程如何挂起--lockSupport.park

被拒绝的线程如何保存恢复执行--内部维护链表保存挂起线程,lockSupport.unpark 唤醒链表挂起线程

同一个线程重复访问如何处理--可重入性保存抢锁线程ID

介绍

对比

实现

步骤

使用方式

公平非公平

可重入

（1）公平选择性：支持非公平（默认）和公平的锁获取方式，吞吐量还是非公平优于公平。
（2）重进入：读锁和写锁都支持线程重进入。
（3）锁降级：遵循获取写锁、获取读锁再释放写锁的次序，写锁能够降级成为读锁。

1 一个变量保存 2 个状态 和 线程池里类似
2 读锁的可重入使用 ThreadLocal 进行存储
3 写锁可以重入
4 写锁降级(没释放锁时候获取读锁，保证数据的一致性)

写饥饿

StampedLock是由Java8时引入的一个性能更好的读写锁

缺点

写锁： 独占锁，一把锁只能被一个线程获得。当一个线程获取写锁后，其他请求读锁和写锁的线程必须等待。类似于 ReentrantReadWriteLock 的写锁，不过这里的写锁是不可重入的。
读锁 （悲观读）：共享锁，没有线程获取写锁的情况下，多个线程可以同时持有读锁。如果己经有线程持有写锁，则其他线程请求获取该读锁会被阻塞。类似于 ReentrantReadWriteLock 的读锁，不过这里的读锁是不可重入的。
乐观读 ：允许多个线程获取乐观读以及读锁。同时允许一个写线程获取写锁。

StampedLock 在获取锁的时候会返回一个 long 型的数据戳，该数据戳用于稍后的锁释放参数，如果返回的数据戳为 0 则表示锁获取失败。当前线程持有了锁再次获取锁还是会返回一个新的数据戳，这也是StampedLock不可重入的原因。此外，在官网给的示例中我们也看到了，StampedLock 还支持这3种锁的转换：
long tryConvertToWriteLock(long stamp){}
long tryConvertToReadLock(long stamp){}
long tryConvertToOptimisticRead(long stamp){}

注意事项

（Java内存模型，Java Memory Model）本身是一种抽象的概念，并不真实存在。它描述的是一组规则或规范，通过这组规范，定了程序中各个变量的访问方法。JMM关于同步的规定：
１）线程解锁前，必须把共享变量的值刷新回主内存；
２）线程加锁前，必须读取主内存的最新值到自己的工作内存；
３）加锁解锁是同一把锁； 

volatile 变量的内存可见性是基于内存屏障（Memory Barrier）实现。
内存屏障又称内存栅栏，是一个 CPU 指令。在程序运行时，为了提高执行性能，编译器和处理器会对指令进行重排序，JMM 为了保证在不同的编译器和 CPU 上有相同的结果，通过插入特定类型的内存屏障来禁止 + 特定类型的编译器重排序和处理器重排序，插入一条内存屏障会告诉编译器和 CPU：不管什么指令都不能和这条 Memory Barrier 指令重排序
指令是LOCK

在 Java 内存模型中，允许编译器和处理器对指令进行重排序，重排序过程不会
影响到单线程程序的执行，但是会影响到多线程并发执行的正确性。
volatile 关键字可以禁止指令重新排序，可以保证一定的有序性。 
单例 防止指令重排

volatile 修饰的变量的有序性有两层含义：
所有在 volatile 修饰的变量写操作之前的写操作，将会对随后该 volatile 修饰的变量读操作之后的语句可见。 happen-before
禁止 JVM 重排序：volatile 修饰的变量的读写指令不能和其前后的任何指令重排序，其前后的指令可能会被重排序。

happen-before 关系是用来判断是否存在数据竞争、线程是否安全的主要依据，也是指令重排序的依据，保证了多线程下的可见性。
volatile 修饰的变量在读写时会建立 happen-before 关系。

只保证单次读/写操作的原子性，对于多步操作，volatile 不能保证原子性，

状态标志

一次性安全发布

独立观察

因为对于 64 位的这两个类型是分为两个 32 位操作的，因为是两次单独的写入，所以就可能导致原子性破坏。

使用 volatile 修饰 long 和 double 类型， 就可以保证值的读取和写入始终是原子的了。

一个线程(或者多个)， 等待另外N个线程完成某个事情之后才能执行

CountDownLatch 的实现原理比较简单，它主要依赖于 AQS(AbstractQueuedSynchronizer)框架来实现线程的同步。
    CountDownLatch 内部维护了一个计数器，该计数器初始值为 N，代表需要等待的线程数目，当一个线程完成了需要等待的任务后，就会调用 countDown() 方法将计数器减 1，当计数器的值为 0 时，等待的线程就会开始执行。
构造函数初始化state=n
countDown方法实现state=state-1，并且如果state=0唤醒await阻塞在AQS队列中线程
await 挂起当前线程,并且加入到AQS队列
自循环阻塞latch线程 当state=0时候退出循环

是一个用于控制同时访问特定资源的线程数量的同步工具。它通过维护一个许可集来管理对资源的访问。线程在访问资源之前必须从信号量中获取许可，访问完成后释放许可。如果没有可用的许可，线程将被阻塞，直到有可用的许可为止。

Semaphore semaphore = new Semaphore(3); // 创建一个具有3个许可的信号量
acquire()：获取一个许可，如果没有可用许可，则等待。
release()：释放一个许可，增加可用许可数。
tryAcquire()：尝试获取一个许可，如果成功则返回 true，否则返回 false。
availablePermits()：返回当前可用的许可数。

限制数据库连接数
控制并发执行的任务数量
控制资源池的访问

优点
简单易用：通过许可数量，轻松控制并发线程数。
高效：避免了不必要的线程创建和销毁，提高了系统吞吐量。
灵活：支持公平和非公平策略，可根据需求选择。
缺点
不保证公平性：默认策略下，先到的线程不一定先获得许可。
可能导致死锁：使用不当（如在持有Semaphore时执行其他阻塞操作）时，可能会引发死锁。 

允许一组线程互相等待，直到所有线程都到达某个屏障（barrier）点，然后这些线程可以继续执行后续的任务，这个屏障是可以循环使用的，也就是说，当所有线程都达到屏障点后，屏障会自动重置，等待下一轮的线程到来

线程同步：当多个线程需要同时进行某些操作，而这些操作需要在所有线程都准备好之后才能开始时，CyclicBarrier可以用来同步这些线程，它可以让一组线程在某个点上等待，直到所有线程都达到这个点，然后这些线程才可以继续执行。
资源分解与任务划分：在处理大量数据或执行复杂任务时，通常会将任务分解成多个子任务，由不同的线程并行处理，CyclicBarrier可以确保在所有子任务完成之前，不会有线程提前进入下一个处理阶段，从而保证了数据的一致性和任务的顺序性。
循环使用：与CountDownLatch不同，CyclicBarrier是可以重复使用的，一旦所有线程都达到了屏障点，屏障会自动重置，这样就可以用于多轮的任务同步。
异常处理：CyclicBarrier还提供了一个特性，即当线程在屏障点等待时，如果某个线程因为异常而中断，那么它可以传播这个异常给其他正在等待的线程，这样可以让所有线程都对异常情况作出响应。
线程间的协作：在某些场景中，线程之间需要紧密协作，比如生产者-消费者模式中的多个消费者线程需要等待所有生产者线程完成生产后才能开始消费，CyclicBarrier可以提供一个集中的同步点，简化线程间的协作逻辑。 

CyclicBarrier(int parties)，构造方法，创建一个新的CyclicBarrier实例，并设置需要等待的线程数（即参与方数量），parties表示需要等待的线程数，当这么多线程调用await()方法后，屏障才会打开，允许线程继续执行。
CyclicBarrier(int parties, Runnable barrierAction)，构造方法，除了设置需要等待的线程数外，还指定了一个当所有线程都达到屏障点时执行的任务（即屏障操作），barrierAction是一个Runnable对象，它的run()方法会在所有线程都到达屏障点后被一个线程调用，barrierAction只会在当前屏障点运行一次，如果屏障被重置，下次所有线程到达时不会再次执行该操作。
int await() throws InterruptedException, BrokenBarrierException，此方法用于让当前线程在屏障点等待，直到所有线程都达到这个屏障点，如果当前线程不是最后一个到达屏障点的线程，那么它会被阻塞，直到所有线程都到达，如果当前线程是最后一个到达的，并且构造方法中指定了barrierAction，那么该操作会由当前线程或另一个线程执行（具体取决于实现），如果在等待过程中线程被中断，或者屏障被其他线程破坏（通过调用reset()方法），那么此方法会抛出异常，返回值是到达屏障点的当前线程的到达顺序，但是这个特性在实际应用中很少使用。
int await(long timeout, TimeUnit unit) throws InterruptedException, BrokenBarrierException, TimeoutException，这个方法与上一个await()方法类似，但是允许指定一个最大等待时间，如果在指定的时间内所有线程都到达了屏障点，那么行为与await()相同，如果超过了指定的时间还没有所有线程到达，那么这个方法会抛出TimeoutException。
int getParties()，返回在CyclicBarrier中需要等待的线程数。
int getNumberWaiting()，返回当前在屏障点等待的线程数。
boolean isBroken()，如果屏障被破坏（可能是因为某个线程在等待时被中断，或者调用了breakBarrier()方法），那么这个方法返回true。
void reset()，将屏障重置为初始状态。这会导致所有当前在屏障点等待的线程抛出BrokenBarrierException，并且屏障可以被重新使用。 

1.CyclicBarrier基于Lock+condition实现的，CountDownLatch继承AQS实现的

2.CyclicBarrier可以重复使用；而CountDownLatch是一次性的，不可重复使用

3.CyclicBarrier中操作计数和阻塞的是同一个线程，调用方法只有一个await方法；
而CountDownLatch中操作计数和阻塞等待是N个线程，控制计数调用方法countDown

优点：
它可以重复使用，非常适合多轮任务同步。
提供了线程间的协作机制，确保任务分阶段完成。
可以指定屏障点操作，当所有线程到达时自动执行。
缺点：
如果线程在等待时被中断或取消，可能会导致BrokenBarrierException。
不适合用于同步访问共享资源，更多是用于任务划分和同步点控制。