本人从事网路安全工作12年，曾在2个大厂工作过，安全服务、售后服务、售前、攻防比赛、安全讲师、销售经理等职位都做过，对这个行业了解比较全面。
最近遍览了各种网络安全类的文章，内容参差不齐，其中不伐有大佬倾力教学，也有各种不良机构浑水摸鱼，在收到几条私信，发现大家对一套完整的系统的网络安全从学习路线到学习资料，甚至是工具有着不小的需求。
最后，我将这部分内容融会贯通成了一套282G的网络安全资料包，所有类目条理清晰，知识点层层递进，需要的小伙伴可以点击下方小卡片领取哦！下面就开始进入正题，如何从一个萌新一步一步进入网络安全行业。
学习路线图
其中最为瞩目也是最为基础的就是网络安全学习路线图，这里我给大家分享一份打磨了3个月，已经更新到4.0版本的网络安全学习路线图。
相比起繁琐的文字，还是生动的视频教程更加适合零基础的同学们学习，这里也是整理了一份与上述学习路线一一对应的网络安全视频教程。
网络安全工具箱
当然，当你入门之后，仅仅是视频教程已经不能满足你的需求了，你肯定需要学习各种工具的使用以及大量的实战项目，这里也分享一份我自己整理的网络安全入门工具以及使用教程和实战。
项目实战
最后就是项目实战，这里带来的是SRC资料&HW资料，毕竟实战是检验真理的唯一标准嘛~
面试题
归根结底，我们的最终目的都是为了就业，所以这份结合了多位朋友的亲身经验打磨的面试题合集你绝对不能错过！
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
public class Java3y {
// 修饰普通方法，此时用的锁是Java3y对象(内置锁)
public synchronized void test() {
// 关注公众号Java3y
// doSomething
}
}
1.4.2修饰代码块：
用的锁是Java3y对象(内置锁)—>this
public class Java3y {
public void test() {
// 修饰代码块，此时用的锁是Java3y对象(内置锁)--->this
synchronized (this){
// 关注公众号Java3y
// doSomething
}
}
}
当然了，我们使用synchronized修饰代码块时未必使用this，还可以使用其他的对象(随便一个对象都有一个内置锁)
所以，我们可以这样干：
public class Java3y {
// 使用object作为锁(任何对象都有对应的锁标记，object也不例外)
private Object object = new Object();
public void test() {
// 修饰代码块，此时用的锁是自己创建的锁Object
synchronized (object){
// 关注公众号Java3y
// doSomething
}
}
}
上面那种方式(随便使用一个对象作为锁)在书上称之为–>客户端锁，这是不建议使用的。
书上想要实现的功能是：给ArrayList添加一个putIfAbsent()，这需要是线程安全的。
假定直接添加synchronized是不可行的
使用客户端锁，会将当前的实现与原本的list耦合了：
书上给出的办法是使用组合的方式(也就是装饰器模式)
1.4.3修饰静态方法
获取到的是类锁(类的字节码文件对象)：Java3y.class
public class Java3y {
// 修饰静态方法代码块，静态方法属于类方法，它属于这个类，获取到的锁是属于类的锁(类的字节码文件对象)-->Java3y.class
public static synchronized void test() {
// 关注公众号Java3y
// doSomething
}
}
1.4.4类锁与对象锁
synchronized修饰静态方法获取的是类锁(类的字节码文件对象)，synchronized修饰普通方法或代码块获取的是对象锁。
- 它俩是不冲突的，也就是说：获取了类锁的线程和获取了对象锁的线程是不冲突的！
public class SynchoronizedDemo {
//synchronized修饰非静态方法
public synchronized void function() throws InterruptedException {
for (int i = 0; i <3; i++) {
Thread.sleep(1000);
System.out.println("function running...");
}
}
//synchronized修饰静态方法
public static synchronized void staticFunction()
throws InterruptedException {
for (int i = 0; i < 3; i++) {
Thread.sleep(1000);
System.out.println("Static function running...");
}
}
public static void main(String[] args) {
final SynchoronizedDemo demo = new SynchoronizedDemo();
// 创建线程执行静态方法
Thread t1 = new Thread(() -> {
try {
staticFunction();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
// 创建线程执行实例方法
Thread t2 = new Thread(() -> {
try {
demo.function();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
// 启动
t1.start();
t2.start();
}
}
结果证明：类锁和对象锁是不会冲突的！
1.5重入锁
我们来看下面的代码：
public class Widget {
// 锁住了
public synchronized void doSomething() {
...
}
}
public class LoggingWidget extends Widget {
// 锁住了
public synchronized void doSomething() {
System.out.println(toString() + ": calling doSomething");
super.doSomething();
}
}
- 当线程A进入到LoggingWidget的
doSomething()方法时，此时拿到了LoggingWidget实例对象的锁。 - 随后在方法上又调用了父类Widget的
doSomething()方法，它又是被synchronized修饰。 - 那现在我们LoggingWidget实例对象的锁还没有释放，进入父类Widget的
doSomething()方法还需要一把锁吗？
不需要的！
因为锁的持有者是“线程”，而不是“调用”。线程A已经是有了LoggingWidget实例对象的锁了，当再需要的时候可以继续**“开锁”**进去的！
这就是内置锁的可重入性。记住，持有锁的是线程。
1.6释放锁的时机
- 当方法(代码块)执行完毕后会自动释放锁，不需要做任何的操作。
- 当一个线程执行的代码出现异常时，其所持有的锁会自动释放。
- 不会由于异常导致出现死锁现象~
二、Lock显式锁
2.1Lock显式锁简单介绍
Lock显式锁是JDK1.5之后才有的，之前我们都是使用Synchronized锁来使线程安全的~
Lock显式锁是一个接口，我们来看看：
随便翻译一下他的顶部注释，看看是干嘛用的：
可以简单概括一下：
- Lock方式来获取锁支持中断、超时不获取、是非阻塞的
- 提高了语义化，哪里加锁，哪里解锁都得写出来
- Lock显式锁可以给我们带来很好的灵活性，但同时我们必须手动释放锁
- 支持Condition条件对象
- 允许多个读线程同时访问共享资源
2.2synchronized锁和Lock锁使用哪个
前面说了，Lock显式锁给我们的程序带来了很多的灵活性，很多特性都是Synchronized锁没有的。那Synchronized锁有没有存在的必要？？
必须是有的！！Lock锁在刚出来的时候很多性能方面都比Synchronized锁要好，但是从JDK1.6开始Synchronized锁就做了各种的优化(毕竟亲儿子，牛逼)
- 优化操作：适应自旋锁，锁消除，锁粗化，轻量级锁，偏向锁。
所以，到现在Lock锁和Synchronized锁的性能其实差别不是很大！而Synchronized锁用起来又特别简单。Lock锁还得顾忌到它的特性，要手动释放锁才行(如果忘了释放，这就是一个隐患)
所以说，我们绝大部分时候还是会使用Synchronized锁，用到了Lock锁提及的特性，带来的灵活性才会考虑使用Lock显式锁~
2.3公平锁
公平锁理解起来非常简单：
- 线程将按照它们发出请求的顺序来获取锁
非公平锁就是：
- 线程发出请求的时可以**“插队”**获取锁
Lock和synchronize都是默认使用非公平锁的。如果不是必要的情况下，不要使用公平锁
- 公平锁会来带一些性能的消耗的
三、Java锁简单总结
本文讲了synchronized内置锁和简单描述了一下Lock显式锁，总得来说：
- synchronized好用，简单，性能不差
- 没有使用到Lock显式锁的特性就不要使用Lock锁了。
五、AQS
本来我是打算在这章节中写Lock的子类实现的，但看到了AQS的这么一个概念，可以说Lock的子类实现都是基于AQS的。
AQS我在面试题中也见过他的身影，但一直不知道是什么东西。所以本篇我就来讲讲AQS这个玩意吧，至少知道它的概念是什么，对吧~
那么接下来我们就开始吧~
一、AQS是什么？
首先我们来普及一下juc是什么：juc其实就是包的缩写(java.util.concurrnt)
- 不要被人家唬到了，以为juc是什么一个牛逼的东西。其实指的是包而已~
我们可以发现lock包下有三个抽象的类：
- AbstractOwnableSynchronizer
- AbstractQueuedLongSynchronizer
- AbstractQueuedSynchronizer
通常地：AbstractQueuedSynchronizer简称为AQS
我们Lock之类的两个常见的锁都是基于它来实现的：
那么我们来看看AbstractQueuedSynchronizer到底是什么，看一个类是干什么的最快途径就是看它的顶部注释
通读了一遍，可以总结出以下比较关键的信息：
- AQS其实就是一个可以给我们实现锁的框架
- 内部实现的关键是：先进先出的队列、state状态
- 定义了内部类ConditionObject
- 拥有两种线程模式
- 独占模式
- 共享模式
- 在LOCK包中的相关锁(常用的有ReentrantLock、 ReadWriteLock)都是基于AQS来构建
- 一般我们叫AQS为同步器
二、简单看看AQS
上面也提到了AQS里边最重要的是状态和队列，我们接下来就看看其源码是怎么样的…
2.1同步状态
使用volatile修饰实现线程可见性：
修改state状态值时使用CAS算法来实现：
2.2先进先出队列
这个队列被称为：CLH队列(三个名字组成)，是一个双向队列
看看它队列源码的组成：
static final class Node {
// 共享
static final Node SHARED = new Node();
// 独占
static final Node EXCLUSIVE = null;
// 线程被取消了
static final int CANCELLED = 1;
// 后继线程需要唤醒
static final int SIGNAL = -1;
// 等待condition唤醒
static final int CONDITION = -2;
// 共享式同步状态获取将会无条件地传播下去(没看懂)
static final int PROPAGATE = -3;
// 初始为0，状态是上面的几种
volatile int waitStatus;
// 前置节点
volatile Node prev;
// 后继节点
volatile Node next;
volatile Thread thread;
Node nextWaiter;
final boolean isShared() {
return nextWaiter == SHARED;
}
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
Node() { // Used to establish initial head or SHARED marker
}
Node(Thread thread, Node mode) { // Used by addWaiter
this.nextWaiter = mode;
this.thread = thread;
}
Node(Thread thread, int waitStatus) { // Used by Condition
this.waitStatus = waitStatus;
this.thread = thread;
}
}
2.3acquire方法
获取独占锁的过程就是在acquire定义的，该方法用到了模板设计模式，由子类实现的~
过程：acquire(int)尝试获取资源，如果获取失败，将线程插入等待队列。插入等待队列后，acquire(int)并没有放弃获取资源，而是根据前置节点状态状态判断是否应该继续获取资源，如果前置节点是头结点，继续尝试获取资源，如果前置节点是SIGNAL状态，就中断当前线程，否则继续尝试获取资源。直到当前线程被park()或者获取到资源，acquire(int)结束。
来源：
2.4release方法
释放独占锁的过程就是在acquire定义的，该方法也用到了模板设计模式，由子类实现的~
过程:首先调用子类的tryRelease()方法释放锁,然后唤醒后继节点,在唤醒的过程中,需要判断后继节点是否满足情况,如果后继节点不为且不是作废状态,则唤醒这个后继节点,否则从tail节点向前寻找合适的节点,如果找到,则唤醒.
来源：
六、ReentrantLock和ReentrantReadWriteLock
上一篇已经将Lock锁的基础AQS简单地过了一遍了，因此本篇主要是讲解Lock锁主要的两个子类：
- ReentrantLock
- ReentrantReadWriteLock
那么接下来我们就开始吧~
一、ReentrantLock锁
首先我们来看看ReentrantLock锁的顶部注释，来看看他的相关特性呗：
来总结一下要点吧：
- 比synchronized更有伸缩性(灵活)
- 支持公平锁(是相对公平的)
- 使用时最标准用法是在try之前调用lock方法，在finally代码块释放锁
class X {
private final ReentrantLock lock = new ReentrantLock();
// ...
public void m() {
lock.lock(); // block until condition holds
try {
// ... method body
} finally {
lock.unlock()
}
}
}
1.1内部类
首先我们可以看到有三个内部类：
这些内部类都是AQS的子类，这就印证了我们之前所说的：AQS是ReentrantLock的基础，AQS是构建锁、同步器的框架
- 可以很清晰的看到，我们的ReentrantLock锁是支持公平锁和非公平锁的~
1.2构造方法
1.3非公平lock方法
尝试获取锁，获取失败的话就调用AQS的acquire(1)方法
acquire(1)方法我们在AQS时简单看过，其中tryAcquire()是子类来实现的
我们去看看tryAcquire()：
1.4公平lock方法
公平的lock方法其实就多了一个状态条件：
这个方法主要是判断当前线程是否位于CLH同步队列中的第一个。如果是则返回flase，否则返回true。
1.5unlock方法
unlock方法也是在AQS中定义的：
去看看tryRelease(arg)是怎么实现的：
二、ReentrantReadWriteLock
我们知道synchronized内置锁和ReentrantLock都是互斥锁(一次只能有一个线程进入到临界区(被锁定的区域))
而ReentrantReadWriteLock是一个读写锁：
- 在读取数据的时候，可以多个线程同时进入到到临界区(被锁定的区域)
- 在写数据的时候，无论是读线程还是写线程都是互斥的
一般来说：我们大多数都是读取数据得多，修改数据得少。所以这个读写锁在这种场景下就很有用了！
读写锁有一个接口ReadWriteLock，定义的方法就两个：
我们还是来看看顶部注释说得啥吧：
其实大概也是说明了：在读的时候可以共享，在写的时候是互斥的
接下来我们还是来看看对应的实现类吧：
按照惯例也简单看看它的顶部注释：
于是我们可以总结出读写锁的一些要点了：
- 读锁不支持条件对象，写锁支持条件对象
- 读锁不能升级为写锁，写锁可以降级为读锁
- 读写锁也有公平和非公平模式
- 读锁支持多个读线程进入临界区，写锁是互斥的
2.1ReentrantReadWriteLock内部类
ReentrantReadWriteLock比ReentrantLock锁多了两个内部类(都是Lock实现)来维护读锁和写锁，但是主体还是使用Syn：
- WriteLock
- ReadLock
2.2读锁和写锁的状态表示
在ReentrantLock锁上使用的是state来表示同步状态(也可以表示重入的次数)，而在ReentrantReadWriteLock是这样代表读写状态的：
2.3写锁的获取
主要还是调用syn的acquire(1)：
进去看看实现：
2.4读锁获取
写锁的获取调用的是acquireShared(int arg)方法：
内部调用的是：doAcquireShared(arg);方法(实现也是在Syn的)，我们来看看：
三、最后
这里就简单总结一下本文的内容吧：
- AQS是ReentrantReadWriteLock和ReentrantLock的基础，因为默认的实现都是在内部类Syn中，而Syn是继承AQS的~
- ReentrantReadWriteLock和ReentrantLock都支持公平和非公平模式，公平模式下会去看FIFO队列线程是否是在队头，而非公平模式下是没有的
- ReentrantReadWriteLock是一个读写锁，如果读的线程比写的线程要多很多的话，那可以考虑使用它。它使用state的变量高16位是读锁，低16位是写锁
- 写锁可以降级为读锁，读锁不能升级为写锁
- 写锁是互斥的，读锁是共享的。
七、线程池
一、线程池简介
线程池可以看做是线程的集合。在没有任务时线程处于空闲状态，当请求到来：线程池给这个请求分配一个空闲的线程，任务完成后回到线程池中等待下次任务**(而不是销毁)。这样就实现了线程的重用**。
我们来看看如果没有使用线程池的情况是这样的：
- 为每个请求都新开一个线程！
public class ThreadPerTaskWebServer {
public static void main(String[] args) throws IOException {
ServerSocket socket = new ServerSocket(80);
while (true) {
// 为每个请求都创建一个新的线程
final Socket connection = socket.accept();
Runnable task = () -> handleRequest(connection);
new Thread(task).start();
}
}
private static void handleRequest(Socket connection) {
// request-handling logic here
}
}
为每个请求都开一个新的线程虽然理论上是可以的，但是会有缺点：
- 线程生命周期的开销非常高。每个线程都有自己的生命周期，创建和销毁线程所花费的时间和资源可能比处理客户端的任务花费的时间和资源更多，并且还会有某些空闲线程也会占用资源。
- 程序的稳定性和健壮性会下降，每个请求开一个线程。如果受到了恶意攻击或者请求过多(内存不足)，程序很容易就奔溃掉了。
所以说：我们的线程最好是交由线程池来管理，这样可以减少对线程生命周期的管理，一定程度上提高性能。
二、JDK提供的线程池API
JDK给我们提供了Excutor框架来使用线程池，它是线程池的基础。
- Executor提供了一种将**“任务提交”与“任务执行”**分离开来的机制(解耦)
下面我们来看看JDK线程池的总体api架构：
接下来我们把这些API都过一遍看看：
Executor接口：
ExcutorService接口：
AbstractExecutorService类：
ScheduledExecutorService接口：
ThreadPoolExecutor类：
ScheduledThreadPoolExecutor类：
2.1ForkJoinPool线程池
除了ScheduledThreadPoolExecutor和ThreadPoolExecutor类线程池以外，还有一个是JDK1.7新增的线程池：ForkJoinPool线程池
于是我们的类图就可以变得完整一些：
JDK1.7中新增的一个线程池，与ThreadPoolExecutor一样，同样继承了AbstractExecutorService。ForkJoinPool是Fork/Join框架的两大核心类之一。与其它类型的ExecutorService相比，其主要的不同在于采用了工作窃取算法(work-stealing)：所有池中线程会尝试找到并执行已被提交到池中的或由其他线程创建的任务。这样很少有线程会处于空闲状态，非常高效。这使得能够有效地处理以下情景：大多数由任务产生大量子任务的情况；从外部客户端大量提交小任务到池中的情况。
来源：
2.2补充：Callable和Future
学到了线程池，我们可以很容易地发现：很多的API都有Callable和Future这么两个东西。
Future<?> submit(Runnable task)
<T> Future<T> submit(Callable<T> task)
其实它们也不是什么高深的东西~~~
我们可以简单认为：Callable就是Runnable的扩展。
- Runnable没有返回值，不能抛出受检查的异常，而Callable可以！
也就是说：当我们的任务需要返回值的时，我们就可以使用Callable！
Future一般我们认为是Callable的返回值，但他其实代表的是任务的生命周期(当然了，它是能获取得到Callable的返回值的)
简单来看一下他们的用法：
public class CallableDemo {
public static void main(String[] args) throws InterruptedException, ExecutionException {
// 创建线程池对象
ExecutorService pool = Executors.newFixedThreadPool(2);
// 可以执行Runnable对象或者Callable对象代表的线程
Future<Integer> f1 = pool.submit(new MyCallable(100));
Future<Integer> f2 = pool.submit(new MyCallable(200));
// V get()
Integer i1 = f1.get();
Integer i2 = f2.get();
System.out.println(i1);
System.out.println(i2);
// 结束
pool.shutdown();
}
}
Callable任务：
public class MyCallable implements Callable<Integer> {
private int number;
public MyCallable(int number) {
this.number = number;
}
@Override
public Integer call() throws Exception {
int sum = 0;
for (int x = 1; x <= number; x++) {
sum += x;
}
return sum;
}
}
执行完任务之后可以获取得到任务返回的数据：
三、ThreadPoolExecutor详解
这是用得最多的线程池，所以本文会重点讲解它。
我们来看看顶部注释：
3.1内部状态
变量ctl定义为AtomicInteger，记录了“线程池中的任务数量”和“线程池的状态”两个信息。
线程的状态：
- RUNNING：线程池能够接受新任务，以及对新添加的任务进行处理。
- SHUTDOWN：线程池不可以接受新任务，但是可以对已添加的任务进行处理。
- STOP：线程池不接收新任务，不处理已添加的任务，并且会中断正在处理的任务。
- TIDYING：当所有的任务已终止，ctl记录的"任务数量"为0，线程池会变为TIDYING状态。当线程池变为TIDYING状态时，会执行钩子函数terminated()。terminated()在ThreadPoolExecutor类中是空的，若用户想在线程池变为TIDYING时，进行相应的处理；可以通过重载terminated()函数来实现。
- TERMINATED：线程池彻底终止的状态。
各个状态之间转换：
3.2已默认实现的池
下面我就列举三个比较常见的实现池：
- newFixedThreadPool
- newCachedThreadPool
- SingleThreadExecutor
如果读懂了上面对应的策略呀，线程数量这些，应该就不会太难看懂了。
3.2.1newFixedThreadPool
一个固定线程数的线程池，它将返回一个corePoolSize和maximumPoolSize相等的线程池。
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}
3.2.2newCachedThreadPool
非常有弹性的线程池，对于新的任务，如果此时线程池里没有空闲线程，线程池会毫不犹豫的创建一条新的线程去处理这个任务。
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}
3.2.3SingleThreadExecutor
使用单个worker线程的Executor
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}
3.3构造方法
我们读完上面的默认实现池还有对应的属性，再回到构造方法看看
- 构造方法可以让我们自定义(扩展)线程池
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}
- 指定核心线程数量
- 指定最大线程数量
- 允许线程空闲时间
- 时间对象
- 阻塞队列
- 线程工厂
- 任务拒绝策略
再总结一遍这些参数的要点：
线程数量要点：
- 如果运行线程的数量少于核心线程数量，则创建新的线程处理请求
- 如果运行线程的数量大于核心线程数量，小于最大线程数量，则当队列满的时候才创建新的线程
- 如果核心线程数量等于最大线程数量，那么将创建固定大小的连接池
- 如果设置了最大线程数量为无穷，那么允许线程池适合任意的并发数量
线程空闲时间要点：
- 当前线程数大于核心线程数，如果空闲时间已经超过了，那该线程会销毁。
排队策略要点：
- 同步移交：不会放到队列中，而是等待线程执行它。如果当前线程没有执行，很可能会新开一个线程执行。
- 无界限策略：如果核心线程都在工作，该线程会放到队列中。所以线程数不会超过核心线程数
- 有界限策略：可以避免资源耗尽，但是一定程度上减低了吞吐量
当线程关闭或者线程数量满了和队列饱和了，就有拒绝任务的情况了：
拒绝任务策略：
- 直接抛出异常
- 使用调用者的线程来处理
- 直接丢掉这个任务
- 丢掉最老的任务
四、execute执行方法
execute执行方法分了三步，以注释的方式写在代码上了~
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
int c = ctl.get();
//如果线程池中运行的线程数量<corePoolSize，则创建新线程来处理请求，即使其他辅助线程是空闲的。
if (workerCountOf(c) < corePoolSize) {
if (addWorker(command, true))
return;
c = ctl.get();
}
//如果线程池中运行的线程数量>=corePoolSize，且线程池处于RUNNING状态，且把提交的任务成功放入阻塞队列中，就再次检查线程池的状态，
// 1.如果线程池不是RUNNING状态，且成功从阻塞队列中删除任务，则该任务由当前 RejectedExecutionHandler 处理。
// 2.否则如果线程池中运行的线程数量为0，则通过addWorker(null, false)尝试新建一个线程，新建线程对应的任务为null。
if (isRunning(c) && workQueue.offer(command)) {
int recheck = ctl.get();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
// 如果以上两种case不成立，即没能将任务成功放入阻塞队列中，且addWoker新建线程失败，则该任务由当前 RejectedExecutionHandler 处理。
else if (!addWorker(command, false))
reject(command);
}
五、线程池关闭
ThreadPoolExecutor提供了shutdown()和shutdownNow()两个方法来关闭线程池
shutdown() ：
shutdownNow():
区别：
- 调用shutdown()后，线程池状态立刻变为SHUTDOWN，而调用shutdownNow()，线程池状态立刻变为STOP。
- shutdown()等待任务执行完才中断线程，而shutdownNow()不等任务执行完就中断了线程。
八、死锁
一、死锁讲解
在Java中使用多线程，就会有可能导致死锁问题。死锁会让程序一直卡住，不再程序往下执行。我们只能通过中止并重启的方式来让程序重新执行。
- 这是我们非常不愿意看到的一种现象，我们要尽可能避免死锁的情况发生！
造成死锁的原因可以概括成三句话：
- 当前线程拥有其他线程需要的资源
- 当前线程等待其他线程已拥有的资源
- 都不放弃自己拥有的资源
1.1锁顺序死锁
首先我们来看一下最简单的死锁(锁顺序死锁)是怎么样发生的：
public class LeftRightDeadlock {
private final Object left = new Object();
private final Object right = new Object();
public void leftRight() {
// 得到left锁
synchronized (left) {
// 得到right锁
synchronized (right) {
doSomething();
}
}
}
public void rightLeft() {
// 得到right锁
synchronized (right) {
// 得到left锁
synchronized (left) {
doSomethingElse();
}
}
}
}
我们的线程是交错执行的，那么就很有可能出现以下的情况：
- 线程A调用
leftRight()方法，得到left锁 - 同时线程B调用
rightLeft()方法，得到right锁 - 线程A和线程B都继续执行，此时线程A需要right锁才能继续往下执行。此时线程B需要left锁才能继续往下执行。
- 但是：线程A的left锁并没有释放，线程B的right锁也没有释放。
- 所以他们都只能等待，而这种等待是无期限的–>永久等待–>死锁
1.2动态锁顺序死锁
我们看一下下面的例子，你认为会发生死锁吗？
// 转账
public static void transferMoney(Account fromAccount,
Account toAccount,
DollarAmount amount)
throws InsufficientFundsException {
// 锁定汇账账户
synchronized (fromAccount) {
// 锁定来账账户
synchronized (toAccount) {
// 判余额是否大于0
if (fromAccount.getBalance().compareTo(amount) < 0) {
throw new InsufficientFundsException();
} else {
// 汇账账户减钱
fromAccount.debit(amount);
// 来账账户增钱
toAccount.credit(amount);
}
}
}
}
上面的代码看起来是没有问题的：锁定两个账户来判断余额是否充足才进行转账！
但是，同样有可能会发生死锁：
- 如果两个线程同时调用
transferMoney() - 线程A从X账户向Y账户转账
- 线程B从账户Y向账户X转账
- 那么就会发生死锁。
A:transferMoney(myAccount,yourAccount,10);
B:transferMoney(yourAccount,myAccount,20);
1.3协作对象之间发生死锁
我们来看一下下面的例子：
public class CooperatingDeadlock {
// Warning: deadlock-prone!
class Taxi {
@GuardedBy("this") private Point location, destination;
private final Dispatcher dispatcher;
public Taxi(Dispatcher dispatcher) {
this.dispatcher = dispatcher;
}
public synchronized Point getLocation() {
return location;
}
// setLocation 需要Taxi内置锁
public synchronized void setLocation(Point location) {
this.location = location;
if (location.equals(destination))
// 调用notifyAvailable()需要Dispatcher内置锁
dispatcher.notifyAvailable(this);
}
public synchronized Point getDestination() {
return destination;
}
public synchronized void setDestination(Point destination) {
this.destination = destination;
}
}
class Dispatcher {
@GuardedBy("this") private final Set<Taxi> taxis;
@GuardedBy("this") private final Set<Taxi> availableTaxis;
public Dispatcher() {
taxis = new HashSet<Taxi>();
availableTaxis = new HashSet<Taxi>();
}
public synchronized void notifyAvailable(Taxi taxi) {
availableTaxis.add(taxi);
}
// 调用getImage()需要Dispatcher内置锁
public synchronized Image getImage() {
Image image = new Image();
for (Taxi t : taxis)
// 调用getLocation()需要Taxi内置锁
image.drawMarker(t.getLocation());
return image;
}
}
class Image {
public void drawMarker(Point p) {
}
}
}
上面的getImage()和setLocation(Point location)都需要获取两个锁的
- 并且在操作途中是没有释放锁的
这就是隐式获取两个锁(对象之间协作)…
这种方式也很容易就造成死锁…
二、避免死锁的方法
避免死锁可以概括成三种方法：
- 固定加锁的顺序(针对锁顺序死锁)
- 开放调用(针对对象之间协作造成的死锁)
- 使用定时锁–>
tryLock()- 如果等待获取锁时间超时，则抛出异常而不是一直等待！
2.1固定锁顺序避免死锁
上面transferMoney()发生死锁的原因是因为加锁顺序不一致而出现的~
- 正如书上所说的：如果所有线程以固定的顺序来获得锁，那么程序中就不会出现锁顺序死锁问题！
那么上面的例子我们就可以改造成这样子：
public class InduceLockOrder {
// 额外的锁、避免两个对象hash值相等的情况(即使很少)
private static final Object tieLock = new Object();
public void transferMoney(final Account fromAcct,
final Account toAcct,
final DollarAmount amount)
throws InsufficientFundsException {
class Helper {
public void transfer() throws InsufficientFundsException {
if (fromAcct.getBalance().compareTo(amount) < 0)
throw new InsufficientFundsException();
else {
fromAcct.debit(amount);
toAcct.credit(amount);
}
}
}
// 得到锁的hash值
int fromHash = System.identityHashCode(fromAcct);
int toHash = System.identityHashCode(toAcct);
// 根据hash值来上锁
if (fromHash < toHash) {
synchronized (fromAcct) {
synchronized (toAcct) {
new Helper().transfer();
}
}
} else if (fromHash > toHash) {// 根据hash值来上锁
synchronized (toAcct) {
synchronized (fromAcct) {
new Helper().transfer();
}
}
} else {// 额外的锁、避免两个对象hash值相等的情况(即使很少)
synchronized (tieLock) {
synchronized (fromAcct) {
synchronized (toAcct) {
new Helper().transfer();
}
}
}
}
}
}
得到对应的hash值来固定加锁的顺序，这样我们就不会发生死锁的问题了！
2.2开放调用避免死锁
在协作对象之间发生死锁的例子中，主要是因为在调用某个方法时就需要持有锁，并且在方法内部也调用了其他带锁的方法！
- 如果在调用某个方法时不需要持有锁，那么这种调用被称为开放调用！
我们可以这样来改造：
- 同步代码块最好仅被用于保护那些涉及共享状态的操作！
class CooperatingNoDeadlock {
@ThreadSafe
class Taxi {
@GuardedBy("this") private Point location, destination;
private final Dispatcher dispatcher;
public Taxi(Dispatcher dispatcher) {
this.dispatcher = dispatcher;
}
public synchronized Point getLocation() {
return location;
}
public synchronized void setLocation(Point location) {
boolean reachedDestination;
// 加Taxi内置锁
synchronized (this) {
this.location = location;
reachedDestination = location.equals(destination);
}
// 执行同步代码块后完毕，释放锁
if (reachedDestination)
// 加Dispatcher内置锁
dispatcher.notifyAvailable(this);
}
public synchronized Point getDestination() {
return destination;
}
public synchronized void setDestination(Point destination) {
this.destination = destination;
}
}
@ThreadSafe
class Dispatcher {
@GuardedBy("this") private final Set<Taxi> taxis;
@GuardedBy("this") private final Set<Taxi> availableTaxis;
public Dispatcher() {
taxis = new HashSet<Taxi>();
availableTaxis = new HashSet<Taxi>();
}
public synchronized void notifyAvailable(Taxi taxi) {
availableTaxis.add(taxi);
}
public Image getImage() {
Set<Taxi> copy;
// Dispatcher内置锁
synchronized (this) {
copy = new HashSet<Taxi>(taxis);
}
// 执行同步代码块后完毕，释放锁
Image image = new Image();
for (Taxi t : copy)
// 加Taix内置锁
image.drawMarker(t.getLocation());
return image;
}
}
class Image {
public void drawMarker(Point p) {
}
}
}
使用开放调用是非常好的一种方式，应该尽量使用它~
2.3使用定时锁
使用显式Lock锁，在获取锁时使用tryLock()方法。当等待超过时限的时候，tryLock()不会一直等待，而是返回错误信息。
使用tryLock()能够有效避免死锁问题~~
2.4死锁检测
虽然造成死锁的原因是因为我们设计得不够好，但是可能写代码的时候不知道哪里发生了死锁。
JDK提供了两种方式来给我们检测：
- JconsoleJDK自带的图形化界面工具，使用JDK给我们的的工具JConsole
- Jstack是JDK自带的命令行工具，主要用于线程Dump分析。
具体可参考：
三、死锁总结
发生死锁的原因主要由于：
- 线程之间交错执行
- 解决：以固定的顺序加锁
- 执行某方法时就需要持有锁，且不释放
- 解决：缩减同步代码块范围，最好仅操作共享变量时才加锁
- 永久等待
- 解决：使用
tryLock()定时锁，超过时限则返回错误信息
- 解决：使用
九、线程常用的工具类
Java为我们提供了三个同步工具类：
- CountDownLatch(闭锁)
- CyclicBarrier(栅栏)
- Semaphore(信号量)
这几个工具类其实说白了就是为了能够更好控制线程之间的通讯问题~
一、CountDownLatch
1.1CountDownLatch简介
- A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.
简单来说：CountDownLatch是一个同步的辅助类，允许一个或多个线程一直等待，直到其它线程完成它们的操作。
它常用的API其实就两个:await()和countDown()
使用说明：
- count初始化CountDownLatch，然后需要等待的线程调用await方法。await方法会一直受阻塞直到count=0。而其它线程完成自己的操作后，调用
countDown()使计数器count减1。当count减到0时，所有在等待的线程均会被释放 - 说白了就是通过count变量来控制等待，如果count值为0了(其他线程的任务都完成了)，那就可以继续执行。
1.2CountDownLatch例子
例子：3y现在去做实习生了，其他的员工还没下班，3y不好意思先走，等其他的员工都走光了，3y再走。
import java.util.concurrent.CountDownLatch;
public class Test {
public static void main(String[] args) {
final CountDownLatch countDownLatch = new CountDownLatch(5);
System.out.println("现在6点下班了.....");
// 3y线程启动
new Thread(new Runnable() {
@Override
public void run() {
try {
// 这里调用的是await()不是wait()
countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("...其他的5个员工走光了，3y终于可以走了");
}
}).start();
// 其他员工线程启动
for (int i = 0; i < 5; i++) {
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("员工xxxx下班了");
countDownLatch.countDown();
}
}).start();
}
}
}
输出结果：
再写个例子：3y现在负责仓库模块功能，但是能力太差了，写得很慢，别的员工都需要等3y写好了才能继续往下写。
import java.util.concurrent.CountDownLatch;
public class Test {
public static void main(String[] args) {
final CountDownLatch countDownLatch = new CountDownLatch(1);
// 3y线程启动
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(5);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("3y终于写完了");
countDownLatch.countDown();
}
}).start();
// 其他员工线程启动
for (int i = 0; i < 5; i++) {
new Thread(new Runnable() {
@Override
public void run() {
System.out.println("其他员工需要等待3y");
try {
countDownLatch.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("3y终于写完了，其他员工可以开始了！");
}
}).start();
}
}
}
输出结果：
二、CyclicBarrier
2.1CyclicBarrier简介
- A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point. CyclicBarriers are useful in programs involving a fixed sized party of threads that must occasionally wait for each other. The barrier is called cyclic because it can be re-used after the waiting threads are released.
简单来说：CyclicBarrier允许一组线程互相等待，直到到达某个公共屏障点。叫做cyclic是因为当所有等待线程都被释放以后，CyclicBarrier可以被重用(对比于CountDownLatch是不能重用的)
使用说明：
- CountDownLatch注重的是等待其他线程完成，CyclicBarrier注重的是：当线程到达某个状态后，暂停下来等待其他线程，所有线程均到达以后，继续执行。
2.2CyclicBarrier例子
例子：3y和女朋友约了去广州夜上海吃东西，由于3y和3y女朋友住的地方不同，自然去的路径也就不一样了。于是他俩约定在体育西路地铁站集合，约定等到相互见面的时候就发一条朋友圈。
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
public class Test {
public static void main(String[] args) {
final CyclicBarrier CyclicBarrier = new CyclicBarrier(2);
for (int i = 0; i < 2; i++) {
new Thread(() -> {
String name = Thread.currentThread().getName();
if (name.equals("Thread-0")) {
name = "3y";
} else {
name = "女朋友";
}
System.out.println(name + "到了体育西");
try {
// 两个人都要到体育西才能发朋友圈
CyclicBarrier.await();
// 他俩到达了体育西，看见了对方发了一条朋友圈：
System.out.println("跟" + name + "去夜上海吃东西~");
} catch (InterruptedException e) {
e.printStackTrace();
} catch (BrokenBarrierException e) {
e.printStackTrace();
}
}).start();
}
}
}
测试结果：
玩了一天以后，各自回到家里，3y和女朋友约定各自洗澡完之后再聊天
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
public class Test {
public static void main(String[] args) {
final CyclicBarrier CyclicBarrier = new CyclicBarrier(2);
for (int i = 0; i < 2; i++) {
new Thread(() -> {
String name = Thread.currentThread().getName();
if (name.equals("Thread-0")) {
name = "3y";
} else {
name = "女朋友";
}
System.out.println(name + "到了体育西");
try {
// 两个人都要到体育西才能发朋友圈
CyclicBarrier.await();
// 他俩到达了体育西，看见了对方发了一条朋友圈：
System.out.println("跟" + name + "去夜上海吃东西~");
// 回家
CyclicBarrier.await();
System.out.println(name + "洗澡");
// 洗澡完之后一起聊天
CyclicBarrier.await();
System.out.println("一起聊天");
} catch (InterruptedException e) {
e.printStackTrace();
} catch (BrokenBarrierException e) {
e.printStackTrace();
}
}).start();
}
}
}
测试结果：
三、Semaphore
3.1Semaphore简介
Semaphores are often used to restrict the number of threads than can access some (physical or logical) resource.
- A counting semaphore. Conceptually, a semaphore maintains a set of permits. Each {@link #acquire} blocks if necessary until a permit is available, and then takes it. Each {@link #release} adds a permit,potentially releasing a blocking acquirer.However, no actual permit objects are used; the {@code Semaphore} just
keeps a count of the number available and acts accordingly.
Semaphore(信号量)实际上就是可以控制同时访问的线程个数，它维护了一组**“许可证”**。
- 当调用
acquire()方法时，会消费一个许可证。如果没有许可证了，会阻塞起来 - 当调用
release()方法时，会添加一个许可证。 - 这些"许可证"的个数其实就是一个count变量罢了~
3.2Semaphore例子
3y女朋友开了一间卖酸奶的小店，小店一次只能容纳5个顾客挑选购买，超过5个就需要排队啦~~~
import java.util.concurrent.Semaphore;
public class Test {
public static void main(String[] args) {
// 假设有50个同时来到酸奶店门口
int nums = 50;
// 酸奶店只能容纳10个人同时挑选酸奶
Semaphore semaphore = new Semaphore(10);
for (int i = 0; i < nums; i++) {
int finalI = i;
new Thread(() -> {
try {
// 有"号"的才能进酸奶店挑选购买
semaphore.acquire();
System.out.println("顾客" + finalI + "在挑选商品，购买...");
// 假设挑选了xx长时间，购买了
Thread.sleep(1000);
// 归还一个许可，后边的就可以进来购买了
System.out.println("顾客" + finalI + "购买完毕了...");
semaphore.release();
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
}
}
输出结果：
反正每次只能5个客户同时进酸奶小店购买挑选。
四、总结
Java为我们提供了三个同步工具类：
- CountDownLatch(闭锁)
- 某个线程等待其他线程执行完毕后，它才执行(其他线程等待某个线程执行完毕后，它才执行)
- CyclicBarrier(栅栏)
- 一组线程互相等待至某个状态，这组线程再同时执行。
- Semaphore(信号量)
- 控制一组线程同时执行。
本文简单的介绍了一下这三个同步工具类是干嘛用的，要深入还得看源码或者借鉴其他的资料。
十、Atomic
一、基础铺垫
首先我们来个例子：
public class AtomicMain {
public static void main(String[] args) throws InterruptedException {
ExecutorService service = Executors.newCachedThreadPool();
Count count = new Count();
// 100个线程对共享变量进行加1
for (int i = 0; i < 100; i++) {
service.execute(() -> count.increase());
}
// 等待上述的线程执行完
service.shutdown();
service.awaitTermination(1, TimeUnit.DAYS);
System.out.println("公众号：Java3y---------");
System.out.println(count.getCount());
}
}
class Count{
// 共享变量
private Integer count = 0;
public Integer getCount() {
return count;
}
public void increase() {
count++;
}
}
你们猜猜得出的结果是多少？是100吗？
多运行几次可以发现：结果是不确定的，可能是95，也可能是98，也可能是100
根据结果我们得知：上面的代码是线程不安全的！如果线程安全的代码，多次执行的结果是一致的！
我们可以发现问题所在：count++并不是原子操作。因为count++需要经过读取-修改-写入三个步骤。举个例子：
- 如果某一个时刻：线程A读到count的值是10，线程B读到count的值也是10
- 线程A对
count++，此时count的值为11 - 线程B对
count++，此时count的值也是11(因为线程B读到的count是10) - 所以到这里应该知道为啥我们的结果是不确定了吧。
要将上面的代码变成线程安全的(每次得出的结果是100)，那也很简单，毕竟我们是学过synchronized锁的人：
- 在
increase()加synchronized锁就好了
public synchronized void increase() {
count++;
}
无论执行多少次，得出的都是100：
从上面的代码我们也可以发现，只做一个++这么简单的操作，都用到了synchronized锁，未免有点小题大做了。
- Synchronized锁是独占的，意味着如果有别的线程在执行，当前线程只能是等待！
于是我们原子变量的类就登场了！
1.2CAS再来看看
在写文章之前，本以为对CAS有一定的了解了(因为之前已经看过相关概念，以为自己理解了)…但真正敲起键盘写的时候，还是发现没完全弄懂…所以再来看看CAS吧。
来源维基百科：
比较并交换(compare and swap, CAS)，是原子操作的一种，可用于在多线程编程中实现不被打断的数据交换操作，从而避免多线程同时改写某一数据时由于执行顺序不确定性以及中断的不可预知性产生的数据不一致问题。 该操作通过将内存中的值与指定数据进行比较，当数值一样时将内存中的数据替换为新的值。
CAS有3个操作数：
- 内存值V
- 旧的预期值A
- 要修改的新值B
当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值(A和内存值V相同时，将内存值V修改为B)，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试(或者什么都不做)。
我们画张图来理解一下：
我们可以发现CAS有两种情况：
- 如果内存值V和我们的预期值A相等，则将内存值修改为B，操作成功！
- 如果内存值V和我们的预期值A不相等，一般也有两种情况：
- 重试(自旋)
- 什么都不做
我们再继续往下看，如果内存值V和我们的预期值A不相等时，应该什么时候重试，什么时候什么都不做。
1.2.1CAS失败重试(自旋)
比如说，我上面用了100个线程，对count值进行加1。我们都知道：如果在线程安全的情况下，这个count值最终的结果一定是为100的。那就意味着：每个线程都会对这个count值实质地进行加1。
我继续画张图来说明一下CAS是如何重试(循环再试)的：
上面图只模拟出两个线程的情况，但足够说明问题了。
1.2.2CAS失败什么都不做
上面是每个线程都要为count值加1，但我们也可以有这种情况：将count值设置为5
我也来画个图说明一下：
理解CAS的核心就是：CAS是原子性的，虽然你可能看到比较后再修改(compare and swap)觉得会有两个操作，但终究是原子性的！
二、原子变量类简单介绍
原子变量类在java.util.concurrent.atomic包下，总体来看有这么多个：
我们可以对其进行分类：
- 基本类型：
- AtomicBoolean：布尔型
- AtomicInteger：整型
- AtomicLong：长整型
- 数组：
- AtomicIntegerArray：数组里的整型
- AtomicLongArray：数组里的长整型
- AtomicReferenceArray：数组里的引用类型
- 引用类型：
- AtomicReference：引用类型
- AtomicStampedReference：带有版本号的引用类型
- AtomicMarkableReference：带有标记位的引用类型
- 对象的属性：
- AtomicIntegerFieldUpdater：对象的属性是整型
- AtomicLongFieldUpdater：对象的属性是长整型
- AtomicReferenceFieldUpdater：对象的属性是引用类型
- JDK8新增DoubleAccumulator、LongAccumulator、DoubleAdder、LongAdder
- 是对AtomicLong等类的改进。比如LongAccumulator与LongAdder在高并发环境下比AtomicLong更高效。
Atomic包里的类基本都是使用Unsafe实现的包装类。
Unsafe里边有几个我们喜欢的方法(CAS)：
// 第一和第二个参数代表对象的实例以及地址，第三个参数代表期望值，第四个参数代表更新值
public final native boolean compareAndSwapObject(Object var1, long var2, Object var4, Object var5);
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
public final native boolean compareAndSwapLong(Object var1, long var2, long var4, long var6);
从原理上概述就是：Atomic包的类的实现绝大调用Unsafe的方法，而Unsafe底层实际上是调用C代码，C代码调用汇编，最后生成出一条CPU指令cmpxchg，完成操作。这也就为啥CAS是原子性的，因为它是一条CPU指令，不会被打断。
2.1原子变量类使用
既然我们上面也说到了，使用Synchronized锁有点小题大作了，我们用原子变量类来改一下：
class Count{
// 共享变量(使用AtomicInteger来替代Synchronized锁)
private AtomicInteger count = new AtomicInteger(0);
public Integer getCount() {
return count.get();
}
public void increase() {
count.incrementAndGet();
}
}
// Main方法还是如上
修改完，无论执行多少次，我们的结果永远是100！
其实Atomic包下原子类的使用方式都不会差太多，了解原子类各种类型，看看API，基本就会用了(网上也写得比较详细，所以我这里果断偷懒了)…
2.2ABA问题
使用CAS有个缺点就是ABA的问题，什么是ABA问题呢？首先我用文字描述一下：
- 现在我有一个变量
count=10，现在有三个线程，分别为A、B、C - 线程A和线程C同时读到count变量，所以线程A和线程C的内存值和预期值都为10
- 此时线程A使用CAS将count值修改成100
- 修改完后，就在这时，线程B进来了，读取得到count的值为100(内存值和预期值都是100)，将count值修改成10
- 线程C拿到执行权，发现内存值是10，预期值也是10，将count值修改成11
上面的操作都可以正常执行完的，这样会发生什么问题呢？？线程C无法得知线程A和线程B修改过的count值，这样是有风险的。
下面我再画个图来说明一下ABA的问题(以链表为例)：
2.3解决ABA问题
要解决ABA的问题，我们可以使用JDK给我们提供的AtomicStampedReference和AtomicMarkableReference类。
AtomicStampedReference：
An {@code AtomicStampedReference} maintains an object referencealong with an integer “stamp”, that can be updated atomically.
简单来说就是在给为这个对象提供了一个版本，并且这个版本如果被修改了，是自动更新的。
原理大概就是：维护了一个Pair对象，Pair对象存储我们的对象引用和一个stamp值。每次CAS比较的是两个Pair对象
// Pair对象
private static class Pair<T> {
final T reference;
final int stamp;
private Pair(T reference, int stamp) {
this.reference = reference;
this.stamp = stamp;
}
static <T> Pair<T> of(T reference, int stamp) {
return new Pair<T>(reference, stamp);
}
}
private volatile Pair<V> pair;
// 比较的是Pari对象
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
因为多了一个版本号比较，所以就不会存在ABA的问题了。
2.4LongAdder性能比AtomicLong要好
如果是 JDK8，推荐使用 LongAdder 对象，比 AtomicLong 性能更好(减少乐观锁的重试次数)。
去查阅了一些博客和资料，大概的意思就是：
- 使用AtomicLong时，在高并发下大量线程会同时去竞争更新同一个原子变量，但是由于同时只有一个线程的CAS会成功，所以其他线程会不断尝试自旋尝试CAS操作，这会浪费不少的CPU资源。
- 而LongAdder可以概括成这样：内部核心数据value分离成一个数组(Cell)，每个线程访问时,通过哈希等算法映射到其中一个数字进行计数，而最终的计数结果，则为这个数组的求和累加。
- 简单来说就是将一个值分散成多个值，在并发的时候就可以分散压力，性能有所提高。
参考资料：
- AtomicLong与LongAdder性能对比https://zhuanlan.zhihu.com/p/45489739
- LongAdder源码详解https://zhuanlan.zhihu.com/p/38288416
十一、ThreadLocal
一、什么是ThreadLocal
声明：本文使用的是JDK 1.8
首先我们来看一下JDK的文档介绍：
/\*\*
\* This class provides thread-local variables. These variables differ from
\* their normal counterparts in that each thread that accesses one (via its
\* {@code get} or {@code set} method) has its own, independently initialized
\* copy of the variable. {@code ThreadLocal} instances are typically private
\* static fields in classes that wish to associate state with a thread (e.g.,
\* a user ID or Transaction ID).
\*
\* <p>For example, the class below generates unique identifiers local to each
\* thread.
\* A thread's id is assigned the first time it invokes {@code ThreadId.get()}
\* and remains unchanged on subsequent calls.
\*/
结合我的总结可以这样理解：ThreadLocal提供了线程的局部变量，每个线程都可以通过set()和get()来对这个局部变量进行操作，但不会和其他线程的局部变量进行冲突，实现了线程的数据隔离～。
简要言之：往ThreadLocal中填充的变量属于当前线程，该变量对其他线程而言是隔离的。
二、为什么要学习ThreadLocal？
从上面可以得出：ThreadLocal可以让我们拥有当前线程的变量，那这个作用有什么用呢？？？
2.1管理Connection
**最典型的是管理数据库的Connection：**当时在学JDBC的时候，为了方便操作写了一个简单数据库连接池，需要数据库连接池的理由也很简单，频繁创建和关闭Connection是一件非常耗费资源的操作，因此需要创建数据库连接池～
那么，数据库连接池的连接怎么管理呢？？我们交由ThreadLocal来进行管理。为什么交给它来管理呢？？ThreadLocal能够实现当前线程的操作都是用同一个Connection，保证了事务！
当时候写的代码：
public class DBUtil {
//数据库连接池
private static BasicDataSource source;
//为不同的线程管理连接
private static ThreadLocal<Connection> local;
static {
try {
//加载配置文件
Properties properties = new Properties();
//获取读取流
InputStream stream = DBUtil.class.getClassLoader().getResourceAsStream("连接池/config.properties");
//从配置文件中读取数据
properties.load(stream);
//关闭流
stream.close();
//初始化连接池
source = new BasicDataSource();
//设置驱动
source.setDriverClassName(properties.getProperty("driver"));
//设置url
source.setUrl(properties.getProperty("url"));
//设置用户名
source.setUsername(properties.getProperty("user"));
//设置密码
source.setPassword(properties.getProperty("pwd"));
//设置初始连接数量
source.setInitialSize(Integer.parseInt(properties.getProperty("initsize")));
//设置最大的连接数量
source.setMaxActive(Integer.parseInt(properties.getProperty("maxactive")));
//设置最长的等待时间
source.setMaxWait(Integer.parseInt(properties.getProperty("maxwait")));
//设置最小空闲数
source.setMinIdle(Integer.parseInt(properties.getProperty("minidle")));
//初始化线程本地
local = new ThreadLocal<>();
} catch (IOException e) {
e.printStackTrace();
}
}
public static Connection getConnection() throws SQLException {
if(local.get()!=null){
return local.get();
}else{
//获取Connection对象
Connection connection = source.getConnection();
//把Connection放进ThreadLocal里面
local.set(connection);
//返回Connection对象
return connection;
}
}
//关闭数据库连接
public static void closeConnection() {
//从线程中拿到Connection对象
Connection connection = local.get();
try {
if (connection != null) {
//恢复连接为自动提交
connection.setAutoCommit(true);
//这里不是真的把连接关了,只是将该连接归还给连接池
connection.close();
//既然连接已经归还给连接池了,ThreadLocal保存的Connction对象也已经没用了
local.remove();
}
} catch (SQLException e) {
e.printStackTrace();
}
}
}
同样的，Hibernate对Connection的管理也是采用了相同的手法(使用ThreadLocal，当然了Hibernate的实现是更强大的)～
2.2避免一些参数传递
避免一些参数的传递的理解可以参考一下Cookie和Session：
- 每当我访问一个页面的时候，浏览器都会帮我们从硬盘中找到对应的Cookie发送过去。
- 浏览器是十分聪明的，不会发送别的网站的Cookie过去，只带当前网站发布过来的Cookie过去
浏览器就相当于我们的ThreadLocal，它仅仅会发送我们当前浏览器存在的Cookie(ThreadLocal的局部变量)，不同的浏览器对Cookie是隔离的(Chrome,Opera,IE的Cookie是隔离的【在Chrome登陆了，在IE你也得重新登陆】)，同样地：线程之间ThreadLocal变量也是隔离的…
那上面避免了参数的传递了吗？？其实是避免了。Cookie并不是我们手动传递过去的，并不需要写<input name= cookie/>来进行传递参数…
在编写程序中也是一样的：日常中我们要去办理业务可能会有很多地方用到身份证，各类证件，每次我们都要掏出来很麻烦
// 咨询时要用身份证，学生证，房产证等等....
public void consult(IdCard idCard,StudentCard studentCard,HourseCard hourseCard){
}
// 办理时还要用身份证，学生证，房产证等等....
public void manage(IdCard idCard,StudentCard studentCard,HourseCard hourseCard) {
}
//......
## 学习路线：
这个方向初期比较容易入门一些，掌握一些基本技术，拿起各种现成的工具就可以开黑了。不过，要想从脚本小子变成黑客大神，这个方向越往后，需要学习和掌握的东西就会越来越多以下是网络渗透需要学习的内容：
**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
**[需要这份系统化资料的朋友，可以点击这里获取](https://bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
351
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
