并发编程

AQS内部原理分析 核心 状态 队列 期望协作工具类实现锁的获取和释放 state状态 而 state 的含义根据具体实现类的作用不同而表示不同的含义 比如说在信号量里面，state 表示的是剩余许可

key泄漏 我们想要清理TL实例，假设我们再ThreadLocalMap的Entry中强引用了TL实例，那么虽然在业务代码中虽然置null，但是Thread类仍然有这个引用链存在，GC的时候发现可达，

Thread、ThreadLocal及ThreadLocalMap三者之间的关系 源码分析 get() getMap() set() ThreadLocalMap 类就是 Thread.threadL

不是，ThreadLocal 并不是用来解决共享资源问题的。虽然 ThreadLocal 确实 可以用于解决多线程情况下的线程安全问题，但其资源并不是共享的，而是每个线程独享的。 ThreadLoca

在通常的业务开发中，ThreadLocal有两种典型的使用场景 场景1，ThreadLocal 用作保存每个线程独享的对象，为每个线程都创建一个副本，这样每个线程都可以修改自己所拥有的副本, 而不会影

容易混淆的东西：JVM内存模型和JMM JVM内存模型和JVM运行时区域有关 Java内存模型和Java并发编程有关（JMM） 这两个是有很大区别的！！ JVM内存模型想必大家都很清楚了 Java代码

背景 先上图 由此可见，非自旋锁如果拿不到锁会把线程阻塞，直到被唤醒；自旋锁拿不到锁会一直尝试 为什么要这样？ 好处 阻塞和唤醒线程都是需要高昂的开销的，如果同步代码块中的内容不复杂，那么可能转换线程

引言 a++：复合操作，不具原子性 可见volatile不能保证原子性 那volatile有什么用？ volatile作用 保证可见性 禁止重排序 volatile场景 布尔标记位 volatile具

为什么要非公平锁？ 背景 公平：排队 非公平：在合适时机插队 非公平还是 ReentrantLock 的默认策略，排队时间不浪费了？ 场景 来看这种场景 那假如公平呢？ 那就进入等待队列等待，依次获得

读锁应该插队吗？什么是锁的升降级？ 背景 ReentrantReadWriteLock可以设置公平或非公平，为什么？ 读锁插队策略 每次获取响应锁之前都要检查能否获取 readerShouldBloc

什么是公平和非公平 首先，我们来看下什么是公平锁和非公平锁，公平锁指的是按照线程请求的顺序，来分配锁；而非公平锁指的是不完全按照请求的顺序，在一定情况下，可以允许插队。但需要注意这里的非公平并不是指完

简介 Lock 接口是 Java 1.5 引入的，最常见的实现类是 ReentrantLock，可以起到“锁”的作用 Lock 和 synchronized 是两种最常见的锁，锁是一种工具，用于控制对

我们主要学习 synchronized 和 Lock 的异同点，以及该如何选择。 相同点 synchronized 和 Lock 的相同点非常多，我们这里重点讲解 3 个比较大的相同点。 synchr

本文我们研究下 synchronized 背后的 monitor 锁。 获取和释放 monitor 锁的时机 我们都知道，最简单的同步方式就是利用 synchronized 关键字来修饰代码块或者修饰

首先我们看下悲观锁与乐观锁是如何进行分类的，悲观锁和乐观锁是从是否锁住资源的角度进行分类 的。 悲观锁 悲观锁比较悲观，它认为如果不锁住这个资源，别的线程就会来争抢，就会造成数据结果错误，所以悲观锁为

1.锁的类别 7种 偏向锁/轻量级锁/重量级锁 可重入所/非可重入锁 共享锁/独占锁 公平锁/非公平锁 悲观锁/乐观锁 自旋锁/非自旋锁 可中断锁/非可中断锁 2.特点 偏向锁/轻量级锁/重量级锁 这

1.final修饰对象只是引用不可变，对象本身可以变 2.final和不可变的关系 关键字 final 可以确保变量的引用保持不变，但是不变性意味着对象一旦创建完毕就不能改变其状态 ，它强调的是对象内

final的三种用法 修饰变量、方法、类 1.修饰变量 一旦赋值不能修改 为什么？ 设计角度：更清晰，不容易出错 线程安全：不可变的对象是线程安全的，不需要我们额外进项同步处理，这些开销是没有的，如果

哲学家就餐问题 有 5 个哲学家，他们面前都有一双筷子，即左手有一根筷子，右手有一根筷子。当然，这个问题有多个版本的描述，可以说是筷子，也可以说是一刀一叉，因为吃牛排的时候，需要刀和叉，缺一不可，也有

为什么String被设计是不可变的？ 看似改变，其实新建了一个字符串"b"，把a的引用指向"b"，原来"a"保持不变 调用subString,replace也是吧应用指向心字符串，没有改变原有字符串内