关于java:一篇博客带你轻松应对java面试中的多线程与高并发

（1）继承 thread 类

thread 类实质是实现了 runnable 接口的一个实例，代表线程的一个实例。启动线程的形式 start 办法。start 是一个本地办法，执行后，执行 run 办法的代码。

（2）实现 runnable 接口

如果本人的类曾经继承了别的类，就不能继承 thread 类。只能实现 runnable 接口。

（3）实现 callable 接口

有返回值的工作必须实现 callable 接口，无返回值的工作必须实现 runnable 接口。执行 callable 接口后，能够获取一个 future 对象，通过 future 对象的 get 办法能够取得返回值。联合线程池能够实现有返回值的多线程。

（4）基于线程池的形式

作为浏览福利，我整顿了 Java 相干的学习笔记 + 面试真题，当初收费分享给浏览到本篇文章的 Java 程序员敌人们，须要的可【点击此处】获取

java 外面线程池的顶级接口是 executor。严格意义上讲。executor 只是一个接口，真正的线程池是 executorservice。

（1）newCachedThreadPool

创立一个可依据须要创立新线程的线程池，然而在以前结构的线程可用时将重用它们。对于执行很多短期异步工作的程序而言，这些线程池通常可进步程序性能。调用 execute 将重用以前结构的线程（如果线程可用）。如果现有线程没有可用的，则创立一个新线程并增加到池中。终止并从缓存中移除那些已有 60 秒钟未被应用的线程。因而，长时间放弃闲暇的线程池不会应用任何资源。

（2）newFixedThreadPool

创立一个可重用固定线程数的线程池，以共享的无界队列形式来运行这些线程。在任意点，在大多数 nThreads 线程会处于解决工作的活动状态。如果在所有线程处于活动状态时提交附加工作，则在有可用线程之前，附加工作将在队列中期待。如果在敞开前的执行期间因为失败而导致任何线程终止，那么一个新线程将代替它执行后续的工作（如果须要）。在某个线程被显式地敞开之前，池中的线程将始终存在。

（3）newScheduledThreadPool

创立一个线程池，它可安顿在给定提早后运行命令或者定期地执行。

（4）newSingleThreadExecutor

Executors.newSingleThreadExecutor()返回一个线程池（这个线程池只有一个线程）, 这个线程池能够在线程死后（或产生异样时）重新启动一个线程来代替原来的线程继续执行上来！

线程的生命周期包含新建 new，就绪 runable，运行 running，阻塞 blocked 和死亡 dead。

（1）新建状态

当程序应用 new 关键字创立了一个线程之后，该线程就属于新建状态，此时仅由 jvm 为其分配内存，并初始化成员变量的值。

（2）就绪状态

当线程对象调用了 start 办法之后。线程处于就绪状态，jvm 会为其创立办法调用栈和程序计数器。此时的现场期待 cpu 的调度。一旦拿到 cpu 就能够立刻执行。

（3）运行状态

处于就绪状态的线程取得了 cpu 的执行权，状态就更改为 running。此时线程处于运行状态。

（4）阻塞状态

阻塞状态是指线程因为某种原因，放弃了 cpu 的使用权，临时进行运行。复原阻塞后进入就绪状态，取得 cpu 使用权之后，才进入执行状态。

阻塞的状况分为三种：

期待阻塞

运行中的线程执行 wait 办法，jvm 会把他放入期待队列中。

同步阻塞

运行的线程获取对象的同步锁的时候，jvm 会把该线程放入锁池中。

其余阻塞

运行中的线程执行线程的 sleep 办法或 join 办法。或者收回 io 申请的时候，jvm 把对象置为阻塞状态。当 sleep 超时，join 或者 io 结束后，就能够拿到 cpu 的权，继续执行。

（5）死亡状态

失常完结，run 或 call 的办法完结。
异样完结，呈现报错
调用 stop，调用 stop 办法可能会产生考虑。

（1）失常执行完结

（2）应用同一标记，多个线程共用一个变量，变量应用 volite 润饰，每次把他作为标记位来进行判断。

（3）interrupt 完结线程

当线程处于阻塞状态的时候，如果应用 sleep，同步锁的 wait 办法，socket 的 receive 办法的时候，会使现场处于阻塞状态。当调用线程的 interrupt 办法的时候。会抛出 interruptexception 异样。阻塞中的那个办法抛出异样，通过代码捕捉异样，而后完结执行。

线程未处于阻塞状态的时候，能够应用 isinterrupted 来进行判断，while 来调这个函数。

（4）stop 办法终止线程

stop 办法强制执行，会导致现场开释他所占有的所有锁、被爱护的数据可能就会呈现不一致性。可能会呈现很多奇怪的应用程序谬误。

对于 sleep 办法，属于 Thread 类，wait 办法数据 object 类中。sleep 办法导致线程的短暂执行，让出 cpu 去执行其余线程。仍然监控 cpu，当工夫到了，立马拿到 cpu 的执行权。

调用 sleep 办法的时候，线程不会开释锁。wait 办法会放弃对象锁，进入锁的期待池。此办法调用了 notify 之后，能力进入锁池，进行从新竞争。

start 办法来启动线程，真正实现了多线程运行。无需期待 run 办法完结。能够间接执行其余办法。
调用 start 办法使线程进入就绪状态，取得 cpu 即可运行。
run 办法是线程的 run 办法执行体。

1. 定义：守护线程 – 也称“服务线程”，他是后盾线程，它有一个个性，即为用户线程提供公共服务，在没有用户线程可服务时会主动来到。

2. 优先级：守护线程的优先级比拟低，用于为零碎中的其它对象和线程提供服务。

3. 设置：通过 setDaemon(true)来设置线程为“守护线程”；将一个用户线程设置为守护线程的形式是在线程对象创立之前用线程对象的 setDaemon 办法。

4. 在 Daemon 线程中产生的新线程也是 Daemon 的。

5. 线程则是 JVM 级别的，以 Tomcat 为例，如果你在 Web 利用中启动一个线程，这个线程的生命周期并不会和 Web 应用程序放弃同步。也就是说，即便你进行了 Web 利用，这个线程仍旧是沉闷的。

6. example: 垃圾回收线程就是一个经典的守护线程，当咱们的程序中不再有任何运行的 Thread, 程序就不会再产生垃圾，垃圾回收器也就无事可做，所以当垃圾回收线程是 JVM 上仅剩的线程时，垃圾回收线程会主动来到。它始终在低级别的状态中运行，用于实时监控和管理系统中的可回收资源。

7. 生命周期：守护过程（Daemon）是运行在后盾的一种非凡过程。它独立于管制终端并且周期性地执行某种工作或期待解决某些产生的事件。也就是说守护线程不依赖于终端，然而依赖于零碎，与零碎“同生共死”。当 JVM 中所有的线程都是守护线程的时候，JVM 就能够退出了；如果还有一个或以上的非守护线则 JVM 不会退出。

乐观锁是一种乐观思维，即认为读多写少，遇到并发写的可能性低，每次去拿数据的时候都认为他人不会批改，所以不会上锁，然而在更新的时候会判断一下在此期间他人有没有去更新这个数据，采取在写时先读出以后版本号，而后加锁操作（比拟跟上一次的版本号，如果一样则更新），如果失败则要反复读 - 比拟 - 写的操作。java 中的乐观锁根本都是通过 CAS 操作实现的，CAS 是一种更新的原子操作，比拟以后值跟传入值是否一样，一样则更新，否则失败。

乐观锁是就是乐观思维，即认为写多，遇到并发写的可能性高，每次去拿数据的时候都认为他人会批改，所以每次在读写数据的时候都会上锁，这样他人想读写这个数据就会 block 直到拿到锁。java 中的乐观锁就是 Synchronized,AQS 框架下的锁则是先尝试 cas 乐观锁去获取锁，获取不到，才会转换为乐观锁，如 RetreenLock。

自旋锁原理非常简单，如果持有锁的线程能在很短时间内开释锁资源，那么那些期待竞争锁的线程就不须要做内核态和用户态之间的切换进入阻塞挂起状态，它们只须要等一等（自旋），等持有锁的线程开释锁后即可立刻获取锁，这样就防止用户线程和内核的切换的耗费。

线程自旋是须要耗费 cup 的，说白了就是让 cup 在做无用功，如果始终获取不到锁，那线程也不能始终占用 cup 自旋做无用功，所以须要设定一个自旋期待的最大工夫。

如果持有锁的线程执行的工夫超过自旋期待的最大工夫扔没有开释锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会进行自旋进入阻塞状态。

自旋锁尽可能的缩小线程的阻塞，这对于锁的竞争不强烈，且占用锁工夫十分短的代码块来说性能能大幅度的晋升，因为自旋的耗费会小于线程阻塞挂起再唤醒的操作的耗费，这些操作会导致线程产生两次上下文切换！然而如果锁的竞争强烈，或者持有锁的线程须要长时间占用锁执行同步块，这时候就不适宜应用自旋锁了，因为自旋锁在获取锁前始终都是占用 cpu 做无用功，占着 XX 不 XX，同时有大量线程在竞争一个锁，会导致获取锁的工夫很长，线程自旋的耗费大于线程阻塞挂起操作的耗费，其它须要 cup 的线程又不能获取到 cpu，造成 cpu 的节约。所以这种状况下咱们要敞开自旋锁；

自旋锁的目标是为了占着 CPU 的资源不开释，等到获取到锁立刻进行解决。然而如何去抉择自旋的执行工夫呢？如果自旋执行工夫太长，会有大量的线程处于自旋状态占用 CPU 资源，进而会影响整体零碎的性能。因而自旋的周期选的额定重要！

JVM 对于自旋周期的抉择，jdk1.5 这个限度是肯定的写死的，在 1.6 引入了适应性自旋锁，适应性自旋锁意味着自旋的工夫不在是固定的了，而是由前一次在同一个锁上的自旋工夫以及锁的拥有者的状态来决定，根本认为一个线程上下文切换的工夫是最佳的一个工夫，同时 JVM 还针对以后 CPU 的负荷状况做了较多的优化，如果均匀负载小于 CPUs 则始终自旋，如果有超过 (CPUs/2) 个线程正在自旋，则起初线程间接阻塞，如果正在自旋的线程发现 Owner 产生了变动则提早自旋工夫（自旋计数）或进入阻塞，如果 CPU 处于节电模式则进行自旋，自旋工夫的最坏状况是 CPU 的存储提早（CPU A 存储了一个数据，到 CPU B 得悉这个数据间接的时间差），自旋时会适当放弃线程优先级之间的差别。

synchronized 它能够把任意一个非 NULL 的对象当作锁。他属于独占式的乐观锁，同时属于可重入锁。

1. 作用于办法时，锁住的是对象的实例(this)；

2. 当作用于静态方法时，锁住的是 Class 实例，又因为 Class 的相干数据存储在永恒带 PermGen（jdk1.8 则是 metaspace），永恒带是全局共享的，因而静态方法锁相当于类的一个全局锁，会锁所有调用该办法的线程；

3. synchronized 作用于一个对象实例时，锁住的是所有以该对象为锁的代码块。它有多个队列，当多个线程一起拜访某个对象监视器的时候，对象监视器会将这些线程存储在不同的容器中。

1) Wait Set：哪些调用 wait 办法被阻塞的线程被搁置在这里；

2) Contention List：竞争队列，所有申请锁的线程首先被放在这个竞争队列中；

3) Entry List：Contention List 中那些有资格成为候选资源的线程被挪动到 Entry List 中；

4) OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为 OnDeck；

5) Owner：以后曾经获取到所资源的线程被称为 Owner；

6) !Owner：以后开释锁的线程。

1. JVM 每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），然而并发状况下，

ContentionList 会被大量的并发线程进行 CAS 拜访，为了升高对尾部元素的竞争，JVM 会将一部分线程挪动到 EntryList 中作为候选竞争线程。

2. Owner 线程会在 unlock 时，将 ContentionList 中的局部线程迁徙到 EntryList 中，并指定 EntryList 中的某个线程为 OnDeck 线程（个别是最先进去的那个线程）。

3. Owner 线程并不间接把锁传递给 OnDeck 线程，而是把锁竞争的权力交给 OnDeck，

OnDeck 须要从新竞争锁。这样尽管就义了一些公平性，然而能极大的晋升零碎的吞吐量，在 JVM 中，也把这种抉择行为称之为“竞争切换”。

4. OnDeck 线程获取到锁资源后会变为 Owner 线程，而没有失去锁资源的依然停留在 EntryList 中。如果 Owner 线程被 wait 办法阻塞，则转移到 WaitSet 队列中，直到某个时刻通过 notify 或者 notifyAll 唤醒，会从新进去 EntryList 中。

5. 处于 ContentionList、EntryList、WaitSet 中的线程都处于阻塞状态，该阻塞是由操作系统

来实现的（Linux 内核下采纳 pthread_mutex_lock 内核函数实现的）。

6. Synchronized 是非偏心锁。Synchronized 在线程进入 ContentionList 时，期待的线程会先尝试自旋获取锁，如果获取不到就进入 ContentionList，这显著对于曾经进入队列的线程是不偏心的，还有一个不偏心的事件就是自旋获取锁的线程还可能间接抢占 OnDeck 线程的锁资源。

7. 每个对象都有个 monitor 对象，加锁就是在竞争 monitor 对象，代码块加锁是在前后别离加上 monitorenter 和 monitorexit 指令来实现的，办法加锁是通过一个标记位来判断的

8. synchronized 是一个重量级操作，须要调用操作系统相干接口，性能是低效的，有可能给线程加锁耗费的工夫比有用操作耗费的工夫更多。

9. Java1.6，synchronized 进行了很多的优化，有适应自旋、锁打消、锁粗化、轻量级锁及偏差锁等，效率有了实质上的进步。在之后推出的 Java1.7 与 1.8 中，均对该关键字的实现机理做了优化。引入了偏差锁和轻量级锁。都是在对象头中有标记位，不须要通过操作系统加锁。

ReentantLock 继承接口 Lock 并实现了接口中定义的办法，他是一种可重入锁，除了能实现 synchronized 所能实现的所有工作外，还提供了诸如可响应中断锁、可轮询锁申请、定时锁等防止多线程死锁的办法。

1. void lock(): 执行此办法时, 如果锁处于闲暇状态, 以后线程将获取到锁. 相同, 如果锁曾经被其余线程持有, 将禁用以后线程, 直到以后线程获取到锁.

2. boolean tryLock()：如果锁可用, 则获取锁, 并立刻返回 true, 否则返回 false. 该办法和 lock()的区别在于, tryLock()只是 ” 试图 ” 获取锁, 如果锁不可用, 不会导致以后线程被禁用, 以后线程依然持续往下执行代码. 而 lock()办法则是肯定要获取到锁, 如果锁不可用, 就始终期待, 在未取得锁之前, 以后线程并不持续向下执行.

3. void unlock()：执行此办法时, 以后线程将开释持有的锁. 锁只能由持有者开释, 如果线程并不持有锁, 却执行该办法, 可能导致异样的产生.

4. Condition newCondition()：条件对象，获取期待告诉组件。该组件和以后的锁绑定，以后线程只有获取了锁，能力调用该组件的 await()办法，而调用后，以后线程将缩放锁。

5. getHoldCount()：查问以后线程放弃此锁的次数，也就是执行此线程执行 lock 办法的次数。

6. getQueueLength（）：返回正等待获取此锁的线程估计数，比方启动 10 个线程，1 个线程取得锁，此时返回的是 9

7. getWaitQueueLength：（Condition condition）返回期待与此锁相干的给定条件的线程估计数。比方 10 个线程，用同一个 condition 对象，并且此时这 10 个线程都执行了 condition 对象的 await 办法，那么此时执行此办法返回 10

8. hasWaiters(Condition condition)：查问是否有线程期待与此锁无关的给定条件(condition)，对于指定 contidion 对象，有多少线程执行了 condition.await 办法

9. hasQueuedThread(Thread thread)：查问给定线程是否期待获取此锁

10. hasQueuedThreads()：是否有线程期待此锁

11. isFair()：该锁是否偏心锁

12. isHeldByCurrentThread()：以后线程是否放弃锁锁定，线程的执行 lock 办法的前后别离是 false 和 true

13. isLock()：此锁是否有任意线程占用

14. lockInterruptibly（）：如果以后线程未被中断，获取锁

15. tryLock（）：尝试取得锁，仅在调用时锁未被线程占用，取得锁

16. tryLock(long timeout TimeUnit unit)：如果锁在给定等待时间内没有被另一个线程放弃，则获取该锁

JVM 按随机、就近准则调配锁的机制则称为不偏心锁，ReentrantLock 在构造函数中提供了是否偏心锁的初始化形式，默认为非偏心锁。非偏心锁理论执行的效率要远远超出偏心锁，除非程序有非凡须要，否则最罕用非偏心锁的分配机制。

偏心锁指的是锁的分配机制是偏心的，通常先对锁提出获取申请的线程会先被调配到锁，ReentrantLock 在构造函数中提供了是否偏心锁的初始化形式来定义偏心锁。

1. ReentrantLock 通过办法 lock()与 unlock()来进行加锁与解锁操作，与 synchronized 会被 JVM 主动解锁机制不同，ReentrantLock 加锁后须要手动进行解锁。为了防止程序出现异常而无奈失常解锁的状况，应用 ReentrantLock 必须在 finally 管制块中进行解锁操作。

2. ReentrantLock 相比 synchronized 的劣势是可中断、偏心锁、多个锁。这种状况下须要应用 ReentrantLock。

1. Condition 类的 awiat 办法和 Object 类的 wait 办法等效

2. Condition 类的 signal 办法和 Object 类的 notify 办法等效

3. Condition 类的 signalAll 办法和 Object 类的 notifyAll 办法等效

4. ReentrantLock 类能够唤醒指定条件的线程，而 object 的唤醒是随机的指定条件唤醒，多建设几个 condition。

1. tryLock 能取得锁就返回 true，不能就立刻返回 false，tryLock(long timeout,TimeUnitunit)，能够减少工夫限度，如果超过该时间段还没取得锁，返回 false。

2. lock 能取得锁就返回 true，不能的话始终期待取得锁。

3. lock 和 lockInterruptibly，如果两个线程别离执行这两个办法，但此时中断这两个线程，lock 不会抛出异样，而 lockInterruptibly 会抛出异样。

如果一个线程领有了这个锁。另一个线程须要这个锁，这个时候进行调用。能够间接调用，不必期待从新获取。

Semaphore 是一种基于计数的信号量。它能够设定一个阈值，基于此，多个线程竞争获取许可信号，做完本人的申请后偿还，超过阈值后，线程申请许可信号将会被阻塞。Semaphore 能够用来构建一些对象池，资源池之类的，比方数据库连接池。

咱们也能够创立计数为 1 的 Semaphore，将其作为一种相似互斥锁的机制，这也叫二元信号量，示意两种互斥状态。

能够创立一个信号量，每个线程耗费一下信号量。用完之后。获取一下残余数量，如果和初始相等，证实线程外部都执行结束了，能够继续执行主线程了。

Semaphore 根本能实现 ReentrantLock 的所有工作，应用办法也与之相似，通过 acquire()与 release()办法来取得和开释临界资源。经实测，Semaphone.acquire()办法默认为可响应中断锁，与 ReentrantLock.lockInterruptibly()作用成果统一，也就是说在期待临界资源的过程中能够被 Thread.interrupt()办法中断。

此外，Semaphore 也实现了可轮询的锁申请与定时锁的性能，除了办法名 tryAcquire 与 tryLock 不同，其应用办法与 ReentrantLock 简直统一。Semaphore 也提供了偏心与非偏心锁的机制，也可在构造函数中进行设定。

Semaphore 的锁开释操作也由手动进行，因而与 ReentrantLock 一样，为防止线程因抛出异样而无奈失常开释锁的状况产生，开释锁的操作也必须在 finally 代码块中实现。

首先阐明，此处 AtomicInteger，一个提供原子操作的 Integer 的类，常见的还有 AtomicBoolean、AtomicInteger、AtomicLong、AtomicReference 等，他们的实现原理雷同，区别在与运算对象类型的不同。令人兴奋地，还能够通过 AtomicReference<V> 将一个对象的所有操作转化成原子操作。咱们晓得，在多线程程序中，诸如 ++i 或 i++ 等运算不具备原子性，是不平安的线程操作之一。

通常咱们会应用 synchronized 将该操作变成一个原子操作，但 JVM 为此类操作特意提供了一些同步类，使得应用更不便，且使程序运行效率变得更高。通过相干材料显示，通常 AtomicInteger 的性能是 ReentantLock 的好几倍。

本文外面讲的是狭义上的可重入锁，而不是单指 JAVA 下的 ReentrantLock。可重入锁，也叫做递归锁，指的是同一线程外层函数取得锁之后，内层递归函数依然有获取该锁的代码，但不受影响。在 JAVA 环境下 ReentrantLock 和 synchronized 都是可重入锁。

偏心锁（Fair）

加锁前查看是否有排队期待的线程，优先排队期待的线程，先来先得

非偏心锁（Nonfair）

加锁时不思考排队期待问题，间接尝试获取锁，获取不到主动到队尾期待

1. 非偏心锁性能比偏心锁高 5~10 倍，因为偏心锁须要在多核的状况下保护一个队列

2. Java 中的 synchronized 是非偏心锁，ReentrantLock 默认的 lock()办法采纳的是非偏心锁。

为了进步性能，Java 提供了读写锁，在读的中央应用读锁，在写的中央应用写锁，灵便管制，如果没有写锁的状况下，读是无阻塞的, 在肯定水平上进步了程序的执行效率。读写锁分为读锁和写锁，多个读锁不互斥，读锁与写锁互斥，这是由 jvm 本人管制的，你只有上好相应的锁即可。

读锁

如果你的代码只读数据，能够很多人同时读，但不能同时写，那就上读锁。

写锁

如果你的代码批改数据，只能有一个人在写，且不能同时读取，那就上写锁。总之，读的时候上读锁，写的时候上写锁！

Java 中读写锁有个接口 java.util.concurrent.locks.ReadWriteLock，也有具体的实现

ReentrantReadWriteLock。

独占锁模式下，每次只能有一个线程能持有锁，ReentrantLock 就是以独占形式实现的互斥锁。

独占锁是一种乐观激进的加锁策略，它防止了读 / 读抵触，如果某个只读线程获取锁，则其余读线程都只能期待，这种状况下就限度了不必要的并发性，因为读操作并不会影响数据的一致性。

共享锁则容许多个线程同时获取锁，并发拜访共享资源，如：ReadWriteLock。共享锁则是一种乐观锁，它放宽了加锁策略，容许多个执行读操作的线程同时访问共享资源。

1. AQS 的外部类 Node 定义了两个常量 SHARED 和 EXCLUSIVE，他们别离标识 AQS 队列中期待线程的锁获取模式。

2. java 的并发包中提供了 ReadWriteLock，读 - 写锁。它容许一个资源能够被多个读操作拜访，或者被一个写操作拜访，但两者不能同时进行。

Synchronized 是通过对象外部的一个叫做监视器锁（monitor）来实现的。然而监视器锁实质又是依赖于底层的操作系统的 Mutex Lock 来实现的。而操作系统实现线程之间的切换这就须要从用户态转换到外围态，这个老本十分高，状态之间的转换须要绝对比拟长的工夫，这就是为什么 Synchronized 效率低的起因。因而，这种依赖于操作系统 Mutex Lock 所实现的锁咱们称之为“重量级锁”。JDK 中对 Synchronized 做的种种优化，其外围都是为了缩小这种重量级锁的应用。

JDK1.6 当前，为了缩小取得锁和开释锁所带来的性能耗费，进步性能，引入了“轻量级锁”和“偏差锁”。

锁的状态总共有四种：无锁状态、偏差锁、轻量级锁和重量级锁。

随着锁的竞争，锁能够从偏差锁降级到轻量级锁，再降级的重量级锁（然而锁的降级是单向的，也就是说只能从低到高降级，不会呈现锁的降级）。

“轻量级”是绝对于应用操作系统互斥量来实现的传统锁而言的。然而，首先须要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，缩小传统的重量级锁应用产生的性能耗费。在解释轻量级锁的执行过程之前，先明确一点，轻量级锁所适应的场景是线程交替执行同步块的状况，如果存在同一时间拜访同一锁的状况，就会导致轻量级锁收缩为重量级锁。

Hotspot 的作者通过以往的钻研发现大多数状况下锁不仅不存在多线程竞争，而且总是由同一线程屡次取得。偏差锁的目标是在某个线程取得锁之后，打消这个线程锁重入（CAS）的开销，看起来让这个线程失去了偏护。引入偏差锁是为了在无多线程竞争的状况下尽量减少不必要的轻量级锁执行门路，因为轻量级锁的获取及开释依赖屡次 CAS 原子指令，而偏差锁只须要在置换 ThreadID 的时候依赖一次 CAS 原子指令（因为一旦呈现多线程竞争的状况就必须撤销偏差锁，所以偏差锁的撤销操作的性能损耗必须小于节省下来的 CAS 原子指令的性能耗费）。下面说过，轻量级锁是为了在线程交替执行同步块时进步性能，而偏差锁则是在只有一个线程执行同步块时进一步提高性能。

分段锁也并非一种理论的锁，而是一种思维 ConcurrentHashMap 是学习分段锁的最好实际。

只用在有线程平安要求的程序上加锁

将大对象（这个对象可能会被很多线程拜访），拆成小对象，大大增加并行度，升高锁竞争。

升高了锁的竞争，偏差锁，轻量级锁成功率才会进步。最最典型的减小锁粒度的案例就是

ConcurrentHashMap。

最常见的锁拆散就是读写锁 ReadWriteLock，依据性能进行拆散成读锁和写锁，这样读读不互斥，读写互斥，写写互斥，即保障了线程平安，又进步了性能。JDK 并发包 1。读写拆散思维能够延长，只有操作互不影响，锁就能够拆散。比方 LinkedBlockingQueue 从头部取出，从尾部放数据。

通常状况下，为了保障多线程间的无效并发，会要求每个线程持有锁的工夫尽量短，即在应用完公共资源后，应该立刻开释锁。然而，凡事都有一个度，如果对同一个锁不停的进行申请、同步和开释，其自身也会耗费零碎贵重的资源，反而不利于性能的优化。

锁打消是在编译器级别的事件。在即时编译器时，如果发现不可能被共享的对象，则能够打消这些对象的锁操作，少数是因为程序员编码不标准引起。

调用该办法的线程进入 WAITING 状态，只有期待另外线程的告诉或被中断才会返回，须要留神的是调用 wait()办法后，会开释对象的锁。因而，wait 办法个别用在同步办法或同步代码块中。

sleep 导致以后线程休眠，与 wait 办法不同的是 sleep 不会开释以后占有的锁,sleep(long)会导致线程进入 TIMED-WATING 状态，而 wait()办法会导致以后线程进入 WATING 状态。

yield 会使以后线程让出 CPU 执行工夫片，与其余线程一起从新竞争 CPU 工夫片。个别状况下，优先级高的线程有更大的可能性胜利竞争失去 CPU 工夫片，但这又不是相对的，有的操作系统对线程优先级并不敏感。

中断一个线程，其本意是给这个线程一个告诉信号，会影响这个线程外部的一个中断标识位。这个线程自身并不会因而而扭转状态(如阻塞，终止等)。

1. 调用 interrupt()办法并不会中断一个正在运行的线程。也就是说处于 Running 状态的线程并不会因为被中断而被终止，仅仅扭转了外部保护的中断标识位而已。

2. 若调用 sleep()而使线程处于 TIMED-WATING 状态，这时调用 interrupt()办法，会抛出 InterruptedException, 从而使线程提前结束 TIMED-WATING 状态。

3. 许多申明抛出 InterruptedException 的办法 (如 Thread.sleep(long mills 办法))，抛出异样前，都会革除中断标识位，所以抛出异样后，调用 isInterrupted() 办法将会返回 false。

4. 中断状态是线程固有的一个标识位，能够通过此标识位平安的终止线程。比方, 你想终止一个线程 thread 的时候，能够调用 thread.interrupt()办法，在线程的 run 办法外部能够依据 thread.isInterrupted()的值来优雅的终止线程。

join() 办法，期待其余线程终止，在以后线程中调用一个线程的 join() 办法，则以后线程转为阻塞状态，回到另一个线程完结，以后线程再由阻塞状态变为就绪状态，期待 cpu 的宠幸。

很多状况下，主线程生成并启动了子线程，须要用到子线程返回的后果，也就是须要主线程须要在子线程完结后再完结，这时候就要用到 join() 办法。

Object 类中的 notify() 办法，唤醒在此对象监视器上期待的单个线程，如果所有线程都在此对象上期待，则会抉择唤醒其中一个线程，抉择是任意的，并在对实现做出决定时产生，线程通过调用其中一个 wait() 办法，在对象的监视器上期待，直到以后的线程放弃此对象上的锁定，能力继续执行被唤醒的线程，被唤醒的线程将以惯例形式与在该对象上被动同步的其余所有线程进行竞争。相似的办法还有 notifyAll()，唤醒再次监视器上期待的所有线程。

1. sleep()：强制一个线程睡眠N毫秒。

2. isAlive()：判断一个线程是否存活。

3. join()：期待线程终止。

4. activeCount()：程序中沉闷的线程数。

5. enumerate()：枚举程序中的线程。

6. currentThread()：失去以后线程。

7. isDaemon()：一个线程是否为守护线程。

8. setDaemon()：设置一个线程为守护线程。(用户线程和守护线程的区别在于，是否期待主线程依赖于主线程完结而完结)

9. setName()：为线程设置一个名称。

10. wait()：强制一个线程期待。

11. notify()：告诉一个线程持续运行。

12. setPriority()：设置一个线程的优先级。

13. getPriority():：取得一个线程的优先级。

奇妙地利用了工夫片轮转的形式, CPU 给每个工作都服务肯定的工夫，而后把当前任务的状态保留下来，在加载下一工作的状态后，持续服务下一工作，工作的状态保留及再加载, 这段过程就叫做上下文切换。工夫片轮转的形式使多个工作在同一颗 CPU 上执行变成了可能。

（有时候也称做工作）是指一个程序运行的实例。在 Linux 零碎中，线程就是能并行运行并且与他们的父过程（创立他们的过程）共享同一地址空间（一段内存区域）和其余资源的轻量级的过程。

是指某一时间点 CPU 寄存器和程序计数器的内容。

是 CPU 外部的数量较少然而速度很快的内存（与之对应的是 CPU 内部绝对较慢的 RAM 主内存）。寄存器通过对罕用值（通常是运算的两头值）的快速访问来进步计算机程序运行的速度。

是一个专用的寄存器，用于表明指令序列中 CPU 正在执行的地位，存的值为正在执行的指令的地位或者下一个将要被执行的指令的地位，具体依赖于特定的零碎。

上下文切换能够认为是内核（操作系统的外围）在 CPU 上对于过程（包含线程）进行切换，上下文切换过程中的信息是保留在过程管制块（PCB, process control block）中的。PCB 还常常被称作“切换桢”（switchframe）。信息会始终保留到 CPU 的内存中，直到他们被再次应用。

1. 挂起一个过程，将这个过程在 CPU 中的状态（上下文）存储于内存中的某处。

2. 在内存中检索下一个过程的上下文并将其在 CPU 的寄存器中复原。

3. 跳转到程序计数器所指向的地位（即跳转到过程被中断时的代码行），以复原该过程在程序中。

1. 以后执行工作的工夫片用完之后，零碎 CPU 失常调度下一个工作；

2. 以后执行工作碰到 IO 阻塞，调度器将此工作挂起，持续下一工作；

3. 多个工作抢占锁资源，当前任务没有抢到锁资源，被调度器挂起，持续下一工作；

4. 用户代码挂起当前任务，让出 CPU 工夫；

5. 硬件中断；

当多个线程同时拜访同一个数据时，很容易呈现问题。为了防止这种状况呈现，咱们要保障线程同步互斥，就是指并发执行的多个线程，在同一时间内只容许一个线程访问共享数据。Java 中能够应用 synchronized 关键字来获得一个对象的同步锁。

何为死锁，就是多个线程同时被阻塞，它们中的一个或者全副都在期待某个资源被开释。

线程池做的工作次要是管制运行的线程的数量，解决过程中将工作放入队列，而后在线程创立后启动这些工作，如果线程数量超过了最大数量超出数量的线程排队等待，等其它线程执行结束，再从队列中取出工作来执行。他的次要特点为：线程复用；管制最大并发数；治理线程。

每一个 Thread 的类都有一个 start 办法。当调用 start 启动线程时 Java 虚构机会调用该类的 run 办法。那么该类的 run() 办法中就是调用了 Runnable 对象的 run() 办法。咱们能够继承重写 Thread 类，在其 start 办法中增加一直循环调用传递过去的 Runnable 对象。这就是线程池的实现原理。循环办法中一直获取 Runnable 是用 Queue 实现的，在获取下一个 Runnable 之前能够是阻塞的。

个别的线程池次要分为以下 4 个组成部分：

1. 线程池管理器：用于创立并治理线程池

2. 工作线程：线程池中的线程

3. 工作接口：每个工作必须实现的接口，用于工作线程调度其运行

4. 工作队列：用于寄存待处理的工作，提供一种缓冲机制

Java 中的线程池是通过 Executor 框架实现的，该框架中用到了 Executor，Executors，ExecutorService，ThreadPoolExecutor，Callable 和 Future、FutureTask 这几个类。

ThreadPoolExecutor 的构造方法如下：

1. corePoolSize：指定了线程池中的线程数量。

2. maximumPoolSize：指定了线程池中的最大线程数量。

3. keepAliveTime：以后线程池数量超过 corePoolSize 时，多余的闲暇线程的存活工夫，即屡次工夫内会被销毁。

4. unit：keepAliveTime 的单位。

5. workQueue：工作队列，被提交但尚未被执行的工作。

6. threadFactory：线程工厂，用于创立线程，个别用默认的即可。

7. handler：回绝策略，当工作太多来不及解决，如何回绝工作。

线程池中的线程曾经用完了，无奈持续为新工作服务，同时，期待队列也曾经排满了，再也塞不下新工作了。这时候咱们就须要回绝策略机制正当的解决这个问题。

JDK 内置的回绝策略如下：

1. AbortPolicy：间接抛出异样，阻止零碎失常运行。

2. CallerRunsPolicy：只有线程池未敞开，该策略间接在调用者线程中，运行以后被抛弃的工作。显然这样做不会真的抛弃工作，然而，工作提交线程的性能极有可能会急剧下降。

3. DiscardOldestPolicy：抛弃最老的一个申请，也就是行将被执行的一个工作，并尝试再次提交当前任务。

4. DiscardPolicy：该策略默默地抛弃无奈解决的工作，不予任何解决。如果容许工作失落，这是最好的一种计划。

以上内置回绝策略均实现了 RejectedExecutionHandler 接口，若以上策略仍无奈满足理论须要，齐全能够本人扩大 RejectedExecutionHandler 接口。

1. 线程池刚创立时，外面没有一个线程。工作队列是作为参数传进来的。不过，就算队列外面有工作，线程池也不会马上执行它们。

2. 当调用 execute() 办法增加一个工作时，线程池会做如下判断：

a) 如果正在运行的线程数量小于 corePoolSize，那么马上创立线程运行这个工作；

b) 如果正在运行的线程数量大于或等于 corePoolSize，那么将这个工作放入队列；

c) 如果这时候队列满了，而且正在运行的线程数量小于 maximumPoolSize，那么还是要创立非核心线程立即运行这个工作；

d) 如果队列满了，而且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会抛出异样 RejectExecutionException。

3. 当一个线程实现工作时，它会从队列中取下一个工作来执行。

4. 当一个线程无事可做，超过肯定的工夫（keepAliveTime）时，线程池会判断，如果以后运行的线程数大于 corePoolSize，那么这个线程就被停掉。所以线程池的所有工作实现后，它最终会膨胀到 corePoolSize 的大小。

阻塞队列，关键字是阻塞，先了解阻塞的含意，在阻塞队列中，线程阻塞有这样的两种状况：

当队列中没有数据的状况下，消费者端的所有线程都会被主动阻塞（挂起），直到有数据放入队列。
当队列中填满数据的状况下，生产者端的所有线程都会被主动阻塞（挂起），直到队列中有空的地位，线程被主动唤醒。

„ 抛出异样：抛出一个异样；

„ 非凡值：返回一个非凡值（null 或 false, 视状况而定）

„ 则塞：在胜利操作之前，始终阻塞线程

„ 超时：放弃前只在最大的工夫内阻塞

1：public abstract boolean add(E paramE)：将指定元素插入此队列中（如果立刻可行且不会违反容量限度），胜利时返回 true，如果以后没有可用的空间，则抛出 IllegalStateException。如果该元素是 NULL，则会抛出 NullPointerException 异样。

2：public abstract boolean offer(E paramE)：将指定元素插入此队列中（如果立刻可行且不会违反容量限度），胜利时返回 true，如果以后没有可用的空间，则返回 false。

3：public abstract void put(E paramE) throws InterruptedException：将指定元素插入此队列中，将期待可用的空间（如果有必要）

public void put(E paramE) throws InterruptedException {checkNotNull(paramE);

 ReentrantLock localReentrantLock = this.lock;

 localReentrantLock.lockInterruptibly();

 try {while (this.count == this.items.length)

 this.notFull.await();// 如果队列满了，则线程阻塞期待

 enqueue(paramE);

 localReentrantLock.unlock();} finally {localReentrantLock.unlock();

 }

 }

4：offer(E o, long timeout, TimeUnit unit)：能够设定期待的工夫，如果在指定的工夫内，还不能往队列中退出 BlockingQueue，则返回失败。

1：poll(time): 取走 BlockingQueue 里排在首位的对象, 若不能立刻取出, 则能够等 time 参数规定的工夫, 取不到时返回 null;

2：poll(long timeout, TimeUnit unit)：从 BlockingQueue 取出一个队首的对象，如果在指定工夫内，队列一旦有数据可取，则立刻返回队列中的数据。否则直到工夫超时还没有数据可取，返回失败。

3：take(): 取走 BlockingQueue 里排在首位的对象, 若 BlockingQueue 为空, 阻断进入期待状态直到 BlockingQueue 有新的数据被退出。

4.drainTo(): 一次性从 BlockingQueue 获取所有可用的数据对象（还能够指定获取数据的个数），通过该办法，能够晋升获取数据效率；不须要屡次分批加锁或开释锁。

1. ArrayBlockingQueue：由数组构造组成的有界阻塞队列。

2. LinkedBlockingQueue：由链表构造组成的有界阻塞队列。

3. PriorityBlockingQueue：反对优先级排序的无界阻塞队列。

4. DelayQueue：应用优先级队列实现的无界阻塞队列。

5. SynchronousQueue：不存储元素的阻塞队列。

6. LinkedTransferQueue：由链表构造组成的无界阻塞队列。

7. LinkedBlockingDeque：由链表构造组成的双向阻塞队列

用数组实现的有界阻塞队列。此队列依照先进先出（FIFO）的准则对元素进行排序。默认状况下不保障访问者偏心的拜访队列，所谓偏心拜访队列是指阻塞的所有生产者线程或消费者线程，当队列可用时，能够依照阻塞的先后顺序拜访队列，即先阻塞的生产者线程，能够先往队列里插入元素，先阻塞的消费者线程，能够先从队列里获取元素。通常状况下为了保障公平性会升高吞吐量。咱们能够应用以下代码创立一个偏心的阻塞队列：

ArrayBlockingQueue fairQueue = new ArrayBlockingQueue(1000,true);

基于链表的阻塞队列，同 ArrayListBlockingQueue 相似，此队列依照先进先出（FIFO）的准则对元素进行排序。而 LinkedBlockingQueue 之所以可能高效的解决并发数据，还因为其对于生产者端和消费者端别离采纳了独立的锁来控制数据同步，这也意味着在高并发的状况下生产者和消费者能够并行地操作队列中的数据，以此来进步整个队列的并发性能。

LinkedBlockingQueue 会默认一个相似有限大小的容量（Integer.MAX_VALUE）。

是一个反对优先级的无界队列。默认状况下元素采取天然程序升序排列。能够自定义实现 compareTo()办法来指定元素进行排序规定，或者初始化 PriorityBlockingQueue 时，指定结构参数 Comparator 来对元素进行排序。须要留神的是不能保障同优先级元素的程序。

是一个反对延时获取元素的无界阻塞队列。队列应用 PriorityQueue 来实现。队列中的元素必须实现 Delayed 接口，在创立元素时能够指定多久能力从队列中获取以后元素。只有在提早期满时能力从队列中提取元素。咱们能够将 DelayQueue 使用在以下利用场景：

1. 缓存零碎的设计：能够用 DelayQueue 保留缓存元素的有效期，应用一个线程循环查问 DelayQueue，一旦能从 DelayQueue 中获取元素时，示意缓存有效期到了。

2. 定时任务调度：应用 DelayQueue 保留当天将会执行的工作和执行工夫，一旦从 DelayQueue 中获取到工作就开始执行，从比方 TimerQueue 就是应用 DelayQueue 实现的。

是一个不存储元素的阻塞队列。每一个 put 操作必须期待一个 take 操作，否则不能持续增加元素。

SynchronousQueue 能够看成是一个传球手，负责把生产者线程解决的数据间接传递给消费者线程。队列自身并不存储任何元素，非常适合于传递性场景, 比方在一个线程中应用的数据，传递给另外一个线程应用，SynchronousQueue 的吞吐量高于 LinkedBlockingQueue 和 ArrayBlockingQueue。

是一个由链表构造组成的无界阻塞 TransferQueue 队列。绝对于其余阻塞队列，LinkedTransferQueue 多了 tryTransfer 和 transfer 办法。

1. transfer 办法：如果以后有消费者正在期待接管元素（消费者应用 take()办法或带工夫限度的 poll()办法时），transfer 办法能够把生产者传入的元素立即 transfer（传输）给消费者。如果没有消费者在期待接管元素，transfer 办法会将元素寄存在队列的 tail 节点，并等到该元素被消费者生产了才返回。

2. tryTransfer 办法。则是用来试探下生产者传入的元素是否能间接传给消费者。如果没有消费者期待接管元素，则返回 false。和 transfer 办法的区别是 tryTransfer 办法无论消费者是否接管，办法立刻返回。而 transfer 办法是必须等到消费者生产了才返回。

对于带有工夫限度的 tryTransfer(E e, long timeout, TimeUnit unit)办法，则是试图把生产者传入的元素间接传给消费者，然而如果没有消费者生产该元素则期待指定的工夫再返回，如果超时还没生产元素，则返回 false，如果在超时工夫内生产了元素，则返回 true。

是一个由链表构造组成的双向阻塞队列。所谓双向队列指的你能够从队列的两端插入和移出元素。双端队列因为多了一个操作队列的入口，在多线程同时入队时，也就缩小了一半的竞争。相比其余的阻塞队列，LinkedBlockingDeque 多了 addFirst，addLast，offerFirst，offerLast，

peekFirst，peekLast 等办法，以 First 单词结尾的办法，示意插入，获取（peek）或移除双端队列的第一个元素。以 Last 单词结尾的办法，示意插入，获取或移除双端队列的最初一个元素。另外插入方法 add 等同于 addLast，移除办法 remove 等效于 removeFirst。然而 take 办法却等同于 takeFirst，不晓得是不是 Jdk 的 bug，应用时还是用带有 First 和 Last 后缀的办法更分明。

在初始化 LinkedBlockingDeque 时能够设置容量避免其过渡收缩。另外双向阻塞队列能够使用在“工作窃取”模式中。

CountDownLatch 类位于 java.util.concurrent 包下，利用它能够实现相似计数器的性能。比方有一个工作 A，它要期待其余 4 个工作执行结束之后能力执行，此时就能够利用 CountDownLatch 来实现这种性能了。

字面意思回环栅栏，通过它能够实现让一组线程期待至某个状态之后再全副同时执行。叫做回环是因为当所有期待线程都被开释当前，CyclicBarrier 能够被重用。咱们暂且把这个状态就叫做 barrier，当调用 await()办法之后，线程就处于 barrier 了。

CyclicBarrier 中最重要的办法就是 await 办法，它有 2 个重载版本：

1. public int await()：用来挂起以后线程，直至所有线程都达到 barrier 状态再同时执行后续工作；

2. public int await(long timeout, TimeUnit unit)：让这些线程期待至肯定的工夫，如果还有

线程没有达到 barrier 状态就间接让达到 barrier 的线程执行后续工作。

具体应用如下，另外 CyclicBarrier 是能够重用的。

Semaphore 翻译成字面意思为信号量，Semaphore 能够管制同时拜访的线程个数，通过 acquire() 获取一个许可，如果没有就期待，而 release() 开释一个许可。

Semaphore 类中比拟重要的几个办法：

1. public void acquire(): 用来获取一个许可，若无许可可能取得，则会始终期待，直到取得许可。

2. public void acquire(int permits): 获取 permits 个许可

3. public void release() {} : 开释许可。留神，在开释许可之前，必须先获取得许可。

4. public void release(int permits) {}: 开释 permits 个许可

下面 4 个办法都会被阻塞，如果想立刻失去执行后果，能够应用上面几个办法

1. public boolean tryAcquire(): 尝试获取一个许可，若获取胜利，则立刻返回 true，若获取失败，则立刻返回 false

2. public boolean tryAcquire(long timeout, TimeUnit unit): 尝试获取一个许可，若在指定的工夫内获取胜利，则立刻返回 true，否则则立刻返回 false

3. public boolean tryAcquire(int permits): 尝试获取 permits 个许可，若获取胜利，则立刻返回 true，若获取失败，则立刻返回 false

4. public boolean tryAcquire(int permits, long timeout, TimeUnit unit): 尝试获取 permits 个许可，若在指定的工夫内获取胜利，则立刻返回 true，否则则立刻返回 false

5. 还能够通过 availablePermits()办法失去可用的许可数目。

例子：若一个工厂有 5 台机器，然而有 8 个工人，一台机器同时只能被一个工人应用，只有应用完了，其余工人能力持续应用。那么咱们就能够通过 Semaphore 来实现：

CountDownLatch 和 CyclicBarrier 都可能实现线程之间的期待，只不过它们侧重点不同；CountDownLatch 个别用于某个线程 A 期待若干个其余线程执行完工作之后，它才执行；而 CyclicBarrier 个别用于一组线程相互期待至某个状态，而后这一组线程再同时执行；另外，CountDownLatch 是不可能重用的，而 CyclicBarrier 是能够重用的。

Semaphore 其实和锁有点相似，它个别用于管制对某组资源的拜访权限。

Java 语言提供了一种稍弱的同步机制，即 volatile 变量，用来确保将变量的更新操作告诉到其余线程。volatile 变量具备两种个性，volatile 变量不会被缓存在寄存器或者对其余处理器不可见的中央，因而在读取 volatile 类型的变量时总会返回最新写入的值。

其一是保障该变量对所有线程可见，这里的可见性指的是当一个线程批改了变量的值，那么新的值对于其余线程是能够立刻获取的。

volatile 禁止了指令重排。比 sychronized 更轻量级的同步锁

在拜访 volatile 变量时不会执行加锁操作，因而也就不会使执行线程阻塞，因而 volatile 变量是一种比 sychronized 关键字更轻量级的同步机制。volatile 适宜这种场景：一个变量被多个线程共享，线程间接给这个变量赋值。

当对非 volatile 变量进行读写的时候，每个线程先从内存拷贝变量到 CPU 缓存中。如果计算机有多个 CPU，每个线程可能在不同的 CPU 上被解决，这意味着每个线程能够拷贝到不同的 CPU cache 中。而申明变量是 volatile 的，JVM 保障了每次读变量都从内存中读，跳过 CPU cache 这一步。

值得阐明的是对 volatile 变量的单次读 / 写操作能够保障原子性的，如 long 和 double 类型变量，然而并不能保障 i++ 这种操作的原子性，因为实质上 i++ 是读、写两次操作。在某些场景下能够代替 Synchronized。然而,volatile 的不能齐全取代 Synchronized 的地位，只有在一些非凡的场景下，能力实用 volatile。总的来说，必须同时满足上面两个条件能力保障在并发环境的线程平安：

（1）对变量的写操作不依赖于以后值（比方 i++），或者说是单纯的变量赋值（booleanflag = true）。

（2）该变量没有蕴含在具备其余变量的不变式中，也就是说，不同的 volatile 变量之间，不能相互依赖。只有在状态真正独立于程序内其余内容时能力应用 volatile。

Java 外面进行多线程通信的次要形式就是共享内存的形式，共享内存次要的关注点有两个：可见性和有序性原子性。Java 内存模型（JMM）解决了可见性和有序性的问题，而锁解决了原子性的问题，现实状况下咱们心愿做到“同步”和“互斥”。有以下惯例实现办法：

将数据抽象成一个类，并将数据的操作作为这个类的办法

将数据抽象成一个类，并将对这个数据的操作作为这个类的办法，这么设计能够和容易做到同步，只有在办法上加”synchronized“。

Runnable 对象作为一个类的外部类

将 Runnable 对象作为一个类的外部类，共享数据作为这个类的成员变量，每个线程对共享数据的操作方法也封装在外部类，以便实现对数据的各个操作的同步和互斥，作为外部类的各个 Runnable 对象调用外部类的这些办法。

ThreadLocal，很多中央叫做线程本地变量，也有些中央叫做线程本地存储，ThreadLocal 的作用是提供线程内的局部变量，这种变量在线程的生命周期内起作用，缩小同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。

1. 每个线程中都有一个本人的 ThreadLocalMap 类对象，能够将线程本人的对象放弃到其中，各管各的，线程能够正确的拜访到本人的对象。

2. 将一个共用的 ThreadLocal 动态实例作为 key，将不同对象的援用保留到不同线程的 ThreadLocalMap 中，而后在线程执行的各处通过这个动态 ThreadLocal 实例的 get()办法获得本人线程保留的那个对象，防止了将这个对象作为参数传递的麻烦。

3. ThreadLocalMap 其实就是线程外面的一个属性，它在 Thread 类中定义 ThreadLocal.ThreadLocalMap threadLocals = null; 应用场景

最常见的 ThreadLocal 应用场景为用来解决数据库连贯、Session 治理等。

1. 都是用来协调多线程对共享对象、变量的拜访

2. 都是可重入锁，同一线程能够屡次取得同一个锁

3. 都保障了可见性和互斥性

1. ReentrantLock 显示的取得、开释锁，synchronized 隐式取得开释锁

2. ReentrantLock 可响应中断、可轮回，synchronized 是不能够响应中断的，为解决锁的不可用性提供了更高的灵活性

3. ReentrantLock 是 API 级别的，synchronized 是 JVM 级别的

4. ReentrantLock 能够实现偏心锁

5. ReentrantLock 通过 Condition 能够绑定多个条件

6. 底层实现不一样，synchronized 是同步阻塞，应用的是乐观并发策略，lock 是同步非阻塞，采纳的是乐观并发策略

7. Lock 是一个接口，而 synchronized 是 Java 中的关键字，synchronized 是内置的语言实现。

8. synchronized 在产生异样时，会主动开释线程占有的锁，因而不会导致死锁景象产生；而 Lock 在产生异样时，如果没有被动通过 unLock()去开释锁，则很可能造成死锁景象，因而应用 Lock 时须要在 finally 块中开释锁。

9. Lock 能够让期待锁的线程响应中断，而 synchronized 却不行，应用 synchronized 时，期待的线程会始终期待上来，不可能响应中断。

10. 通过 Lock 能够晓得有没有胜利获取锁，而 synchronized 却无奈办到。

11. Lock 能够进步多个线程进行读操作的效率，既就是实现读写锁等。

抢占式调度指的是每条线程执行的工夫、线程的切换都由系统控制，系统控制指的是在零碎某种运行机制下，可能每条线程都分同样的执行工夫片，也可能是某些线程执行的工夫片较长，甚至某些线程得不到执行的工夫片。在这种机制下，一个线程的梗塞不会导致整个过程梗塞。

协同式调度指某一线程执行完后被动告诉零碎切换到另一线程上执行，这种模式就像接力赛一样，一个人跑完本人的途程就把接力棒交接给下一个人，下集体持续往下跑。线程的执行工夫由线程自身管制，线程切换能够预知，不存在多线程同步问题，但它有一个致命弱点：如果一个线程编写有问题，运行到一半就始终梗塞，那么可能导致整个零碎解体。

java 应用的线程调应用抢占式调度，Java 中线程会按优先级调配 CPU 工夫片运行，且优先级越高越优先执行，但优先级高并不代表能单独占用执行工夫片，可能是优先级高失去越多的执行工夫片，反之，优先级低的分到的执行工夫少但不会调配不到执行工夫。

1. 以后运行线程被动放弃 CPU，JVM 临时放弃 CPU 操作（基于工夫片轮转调度的 JVM 操作系统不会让线程永恒放弃 CPU，或者说放弃本次工夫片的执行权），例如调用 yield()办法。

2. 以后运行线程因为某些起因进入阻塞状态，例如阻塞在 I/O 上。

3. 以后运行线程完结，即运行完 run()办法外面的工作。

CAS（Compare And Swap/Set）比拟并替换，CAS 算法的过程是这样：它蕴含 3 个参数

CAS(V,E,N)。V 示意要更新的变量(内存值)，E 示意预期值(旧的)，N 示意新值。当且仅当 V 值等于 E 值时，才会将 V 的值设为 N，如果 V 值和 E 值不同，则阐明曾经有其余线程做了更新，则以后线程什么都不做。最初，CAS 返回以后 V 的实在值。

CAS 操作是抱着乐观的态度进行的(乐观锁)，它总是认为本人能够胜利实现操作。当多个线程同时应用 CAS 操作一个变量时，只有一个会胜出，并胜利更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且容许再次尝试，当然也容许失败的线程放弃操作。基于这样的原理，CAS 操作即便没有锁，也能够发现其余线程对以后线程的烦扰，并进行失当的解决。

JDK1.5 的原子包：java.util.concurrent.atomic 这个包外面提供了一组原子类。其根本的个性就是在多线程环境下，当有多个线程同时执行这些类的实例蕴含的办法时，具备排他性，即当某个线程进入办法，执行其中的指令时，不会被其余线程打断，而别的线程就像自旋锁一样，始终等到该办法执行实现，才由 JVM 从期待队列中抉择一个另一个线程进入，这只是一种逻辑上的了解。

绝对于对于 synchronized 这种阻塞算法，CAS 是非阻塞算法的一种常见实现。因为个别 CPU 切换工夫比 CPU 指令集操作更加长，所以 J.U.C 在性能上有了很大的晋升。如下代码。

getAndIncrement 采纳了 CAS 操作，每次从内存中读取数据而后将此数据和 +1 后的后果进行 CAS 操作，如果胜利就返回后果，否则重试直到胜利为止。而 compareAndSet 利用 JNI 来实现 CPU 指令的操作。

CAS 会导致“ABA 问题”。CAS 算法实现一个重要前提须要取出内存中某时刻的数据，而在下时刻比拟并替换，那么在这个时间差类会导致数据的变动。

比如说一个线程 one 从内存地位 V 中取出 A，这时候另一个线程 two 也从内存中取出 A，并且 two 进行了一些操作变成了 B，而后 two 又将 V 地位的数据变成 A，这时候线程 one 进行 CAS 操作发现内存中依然是 A，而后 one 操作胜利。只管线程 one 的 CAS 操作胜利，然而不代表这个过程就是没有问题的。

局部乐观锁的实现是通过版本号（version）的形式来解决 ABA 问题，乐观锁每次在执行数据的批改操作时，都会带上一个版本号，一旦版本号和数据的版本号统一就能够执行批改操作并对版本号执行 +1 操作，否则就执行失败。因为每次操作的版本号都会随之减少，所以不会呈现 ABA 问题，因为版本号只会减少不会缩小。

AbstractQueuedSynchronizer 类如其名，形象的队列式的同步器，AQS 定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如罕用的 ReentrantLock/Semaphore/CountDownLatch。

它保护了一个 volatile int state（代表共享资源）和一个 FIFO 线程期待队列（多线程争用资源被阻塞时会进入此队列）。这里 volatile 是外围关键词，具体 volatile 的语义，在此不述。state 的

拜访形式有三种:

getState()
setState()
compareAndSetState()

AQS 定义两种资源共享形式

xclusive 独占资源 -ReentrantLock

Exclusive（独占，只有一个线程能执行，如 ReentrantLock）

Share 共享资源 -Semaphore/CountDownLatch

Share（共享，多个线程可同时执行，如 Semaphore/CountDownLatch）。

AQS 只是一个框架，具体资源的获取 / 开释形式交由自定义同步器去实现，AQS 这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了（通过 state 的 get/set/CAS)之所以没有定义成 abstract，是因为独占模式下只用实现 tryAcquire-tryRelease，而共享模式下只用实现 tryAcquireShared-tryReleaseShared。如果都定义成 abstract，那么每个模式也要去实现另一模式下的接口。不同的自定义同步器争用共享资源的形式也不同。自定义同步器在实现时只须要实现共享资源 state 的获取与开释形式即可，至于具体线程期待队列的保护（如获取资源失败入队 / 唤醒出队等），AQS 曾经在顶层实现好了。自定义同步器实现时次要实现以下几种办法：

1．isHeldExclusively()：该线程是否正在独占资源。只有用到 condition 才须要去实现它。

2．tryAcquire(int)：独占形式。尝试获取资源，胜利则返回 true，失败则返回 false。3．tryRelease(int)：独占形式。尝试开释资源，胜利则返回 true，失败则返回 false。4．tryAcquireShared(int)：共享形式。尝试获取资源。正数示意失败；0 示意胜利，但没有残余可用资源；负数示意胜利，且有残余资源。

5．tryReleaseShared(int)：共享形式。尝试开释资源，如果开释后容许唤醒后续期待结点返回 true，否则返回 false。

同步器的实现是 ABS 外围（state 资源状态计数）

同步器的实现是 ABS 外围，以 ReentrantLock 为例，state 初始化为 0，示意未锁定状态。A 线程 lock()时，会调用 tryAcquire()独占该锁并将 state+1。尔后，其余线程再 tryAcquire()时就会失败，直到 A 线程 unlock()到 state=0（即开释锁）为止，其它线程才有机会获取该锁。当然，开释锁之前，A 线程本人是能够反复获取此锁的（state 会累加），这就是可重入的概念。但要留神，获取多少次就要开释如许次，这样能力保障 state 是能回到零态的。

以 CountDownLatch 以例，工作分为 N 个子线程去执行，state 也初始化为 N（留神 N 要与线程个数统一）。这 N 个子线程是并行执行的，每个子线程执行完后 countDown()一次，state 会 CAS 减 1。等到所有子线程都执行完后 (即 state=0)，会 unpark() 主调用线程，而后主调用线程就会从 await()函数返回，持续后余动作。

ReentrantReadWriteLock 实现独占和共享两种形式

一般来说，自定义同步器要么是独占办法，要么是共享形式，他们也只需实现 tryAcquiretryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也反对自定义同步器同时实现独占和共享两种形式，如 ReentrantReadWriteLock。

关于java:一篇博客带你轻松应对java面试中的多线程与高并发

1. Java 线程的创立形式

2. 介绍一下 java 的线程池

3. 线程的申明周期

4. 终止线程的四种形式

5. sleep 和 wait 办法的区别

6. start 与 run 办法的区别

7. Java 的后盾过程

8. Java 的锁

乐观锁

乐观锁

自旋锁

自旋锁的优缺点

自旋锁工夫阈值

Synchronized 同步锁

Synchronized 作用范畴

Synchronized 外围组件

ReentrantLock

Lock 接口的次要办法

非偏心锁

偏心锁

ReentrantLock 与 synchronized

Condition 类和 Object 类锁办法区别区别

tryLock 和 lock 和 lockInterruptibly 的区别

可重入锁的益处

Semaphore 信号量

实现互斥锁（计数器为 1）

代码实现

其余用处

Semaphore 与 ReentrantLock

AtomicInteger

可重入锁（递归锁）

偏心锁与非偏心锁

ReadWriteLock 读写锁

共享锁和独占锁

独占锁

共享锁

重量级锁（Mutex Lock）

轻量级锁

锁降级

偏差锁

分段锁

锁优化

缩小锁持有工夫

减小锁粒度

锁拆散

锁粗化

锁打消

9. 线程根本办法

线程期待（wait）

线程睡眠（sleep）

线程退让（yield）

线程中断（interrupt）

Join 期待其余线程终止

为什么要用 join()办法？

线程唤醒（notify）

其余办法

10. 线程的上下文切换

线程

上下文

寄存器

程序计数器

PCB-“切换桢

上下文切换的流动

引起线程上下文切换的起因

11. 同步锁与死锁

同步锁

死锁

12. 线程池原理

线程复用

线程池的组成

回绝策略

Java 线程池工作过程

13. JAVA 阻塞队列原理

阻塞队列的次要办法

插入操作：

获取数据操作：

Java 中的阻塞队列

ArrayBlockingQueue（偏心、非偏心）

LinkedBlockingQueue（两个独立锁进步并发）

Just My Socks（注册教程内含优惠码）