1. 创建线程的四种方式
- 实现Runnable 重写run方法
- 继承Thread 重写run方法
- 线程池创建 Executors.newCachedThreadPool()
- 实现Callable接口
2. Thread线程操作方法
当前线程睡眠指定mills毫秒
- Thread.sleep([mills])
当前线程优雅让出执行权
- Thread.yield()
例如Thread t1, t2,在t2的run方法中调用t1.join(),线程t2将等待t1完成后执行
- join
3. Thread状态
状态 | 使用场景 |
---|---|
NEW | Thread被创建之后,未start之前 |
RUNNABLE | 在调用start()方法之后,这也是线程进入运行状态的唯一一种方式。 具体分为ready跟running,当线程被挂起或者调用Thread.yield()的时候为ready |
WAITING | 当一个线程执行了Object.wait()的时候,它一定在等待另一个线程执行Object.notify()或者Object.notifyAll()。 或者一个线程thread,其在主线程中被执行了thread.join()的时候,主线程即会等待该线程执行完成。当一个线程执行了LockSupport.park()的时候,其在等待执行LockSupport.unpark(thread)。当该线程处于这种等待的时候,其状态即为WAITING。需要关注的是,这边的等待是没有时间限制的,当发现有这种状态的线程的时候,若其长时间处于这种状态,也需要关注下程序内部有无逻辑异常。 |
TIMED_WAITING | 这个状态和WAITING状态的区别就是,这个状态的等待是有一定时效的 Thread.sleep(long) Object.wait(long) Thread.join(long) LockSupport.parkNanos() LockSupport.parkUntil() |
BLOCKED | 在进入synchronized关键字修饰的方法或代码块(获取锁)时的状态 |
TERMINATED | 线程执行结束之后的状态。 线程一旦终止了,就不能复生。 在一个终止的线程上调用start()方法,会抛出java.lang.IllegalThreadStateException异常 |
4. synchronized
- 锁住的是对象而不是代码
- this 等价于 当前类.class
- 锁定方法,非锁定方法同时进行
- 锁在执行过程中发生异常会自动释放锁
- synchronized获得的锁是可重入的
- 锁升级 偏向锁-自旋锁-重量级锁
- synchronized(object)不能用String常量/Integer,Long等基本数据类型
- 锁定对象的时候要保证对象不能被重写,最好加final定义
4. volatile
- 保证线程可见性
- 禁止指令重排序
- volatile并不能保证多个线程修改的一致性,要保持一致性还是需要synchronized关键字
- volatile 引用类型(包括数组)只能保证引用本身的可见性,不能保证内部字段的可见性
volatile关 键字只能用于变量而不可以修饰方法以及代码块
5. synchronized与AtomicLong以及LongAdder的效率对比
Synchronized 是需要加锁的,效率偏低;
AtomicLong 不需要申请锁,使用CAS机制;
LongAdder 使用分段锁,所以效率好,在并发数量特别高的时候,LongAdder最合适
6. ConcurrentHashMap的分段锁原理
分段锁就是将数据分段上锁,把锁进一步细粒度化,有助于提升并发效率。
HashTable容器在竞争激烈的并发环境下表现出效率低下的原因是所有访问HashTable的线程都必须竞争同一把锁,假如容器里有多把锁,每一把锁用于锁容器其中一部分数据,那么当多线程访问容器里不同数据段的数据时,线程间就不会存在锁竞争,从而可以有效提高并发访问效率,这就是ConcurrentHashMap所使用的锁分段技术。首先将数据分成一段一段地存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据的时候,其他段的数据也能被其他线程访问。
7. ReentrantLock
ReentrantLock可以替代synchronized
但是ReentrantLock必须手动开启锁/关闭锁,synchronized遇到异常会自动释放锁,ReentrantLock需要手动关闭,一般都是放在finally中关闭
定义锁 Lock lock = new ReentrantLock();
开启 lock.lock();
关闭 lock.unlock();
使用Reentrantlock可以进行“尝试锁定”tryLock,这样无法锁定,或者在指定时间内无法锁定,线程可以决定是否继续等待。
使用tryLock进行尝试锁定,不管锁定与否,方法都将继续执行
可以根据tryLock的返回值来判定是否锁定
也可以指定tryLock的时间,由于tryLock(time)抛出异常,所以要注意unclock的处理,必须放到finally中,如果tryLock未锁定,则不需要unlock
使用ReentrantLock还可以调用lockInterruptibly方法,可以对线程interrupt方法做出响应,在一个线程等待锁的过程中,可以被打断
new ReentrantLock(true) 表示公平锁,不带参数默认为false,非公平锁
8. CountDownLatch
countDownLatch这个类可以使一个线程等待其他线程各自执行完毕后再执行。
是通过一个计数器来实现的,计数器的初始值是线程的数量。当调用countDown()方法后,每当一个线程执行完毕后,计数器的值就-1,当计数器的值为0时,表示所有线程都执行完毕,然后在闭锁上等待的线程就可以恢复工作了。线程中调用countDown()方法开始计数;
在调用await()方法的线程中,当计数器为0是后续才会继续执行,否则一直等待;
也可以使用latch.await(timeout, unit)在等待timeout时间后如果计数器不为0,线程仍将继续。
countDown()之后的代码不受计数器控制
与join区别,使用join的线程将被阻塞,使用countDown的线程不受影响,只有调用await的时候才会阻塞
8. CyclicBarrier
作用就是会让指定数量的(数量由构造函数指定)所有线程都等待完成后才会继续下一步行动。
构造函数:
public CyclicBarrier(int parties)
public CyclicBarrier(int parties, Runnable barrierAction)
parties 是线程的个数;
barrierAction为最后一个到达线程要做的任务
所有线程会等待全部线程到达栅栏之后才会继续执行,并且最后到达的线程会完成 Runnable 的任务。
实现原理:在CyclicBarrier的内部定义了一个Lock对象,每当一个线程调用await方法时,将拦截的线程数减1,然后判断剩余拦截数是否为初始值parties,如果不是,进入Lock对象的条件队列等待。如果是,执行barrierAction对象的Runnable方法,然后将锁的条件队列中的所有线程放入锁等待队列中,这些线程会依次的获取锁、释放锁。
9. Phaser
可重复使用的同步屏障,功能类似于CyclicBarrier和CountDownLatch,但支持更灵活的使用。
Phaser使我们能够建立在逻辑线程需要才去执行下一步的障碍等。
我们可以协调多个执行阶段,为每个程序阶段重用Phaser实例。每个阶段可以有不同数量的线程等待前进到另一个阶段。我们稍后会看一个使用阶段的示例。
要参与协调,线程需要使用Phaser实例 register() 本身。请注意:这只会增加注册方的数量,我们无法检查当前线程是否已注册 - 我们必须将实现子类化以支持此操作。
线程通过调用 arriAndAwaitAdvance() 来阻止它到达屏障,这是一种阻塞方法。当数量到达等于注册的数量时,程序的执行将继续,并且数量将增加。我们可以通过调用getPhase()方法获取当前数量。
10. ReadWriteLock
ReadWriteLock的具体实现是ReentrantReadWriteLock
ReadWriteLock允许分别创建读锁跟写锁
ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
Lock readLock = readWriteLock.readLock();
Lock writeLock = readWriteLock.writeLock();
使用ReadWriteLock时,适用条件是同一个数据,有大量线程读取,但仅有少数线程修改。
ReadWriteLock可以保证:
- 只允许一个线程写入(其他线程既不能写入也不能读取);
- 没有写入时,多个线程允许同时读(提高性能)
读写分离锁可以有效地帮助减少锁竞争,以提高系统性能,读写锁读读之间不互斥,读写,写写都是互斥的
11. Semaphore
Semaphore 是一个计数信号量,必须由获取它的线程释放。常用于限制可以访问某些资源的线程数量,例如通过 Semaphore 限流。
对于Semaphore来说,它要保证的是资源的互斥而不是资源的同步,在同一时刻是无法保证同步的,但是却可以保证资源的互斥。只是限制了访问某些资源的线程数,其实并没有实现同步。常用方法:
1、acquire(int permits)从此信号量获取给定数目的许可,在提供这些许可前一直将线程阻塞,或者线程已被中断。就好比是一个学生占两个窗口。这同时也对应了相应的release方法。
2、release(int permits)
释放给定数目的许可,将其返回到信号量。这个是对应于上面的方法,一个学生占几个窗口完事之后还要释放多少
3、availablePermits()
返回此信号量中当前可用的许可数。也就是返回当前还有多少个窗口可用。
4、reducePermits(int reduction)
根据指定的缩减量减小可用许可的数目。
5、hasQueuedThreads()
查询是否有线程正在等待获取资源。
6、getQueueLength()
返回正在等待获取的线程的估计数目。该值仅是估计的数字。
7、tryAcquire(int permits, long timeout, TimeUnit unit)
如果在给定的等待时间内此信号量有可用的所有许可,并且当前线程未被中断,则从此信号量获取给定数目的许可。
8、acquireUninterruptibly(int permits)
从此信号量获取给定数目的许可,在提供这些许可前一直将线程阻塞。
12. Exchanger
用于两个工作线程之间交换数据的封装工具类,简单说就是一个线程在完成一定的事务后想与另一个线程交换数据,则第一个先拿出数据的线程会一直等待第二个线程,直到第二个线程拿着数据到来时才能彼此交换对应数据。其定义为 Exchanger 泛型类型,其中 V 表示可交换的数据类型,对外提供的接口很简单,具体如下:
Exchanger():无参构造方法。
V exchange(V v):等待另一个线程到达此交换点(除非当前线程被中断),然后将给定的对象传送给该线程,并接收该线程的对象。
V exchange(V v, long timeout, TimeUnit unit):等待另一个线程到达此交换点(除非当前线程被中断或超出了指定的等待时间),然后将给定的对象传送给该线程,并接收该线程的对象。
13. LockSupport
LockSupport 是一个非常方便实用的线程阻塞工具,他可以在任意位置让线程阻塞。
LockSupport 的静态方法 park()可以阻塞当前线程,类似的还有 parkNanos(),parkUntil()等,他们实现了一个限时的等待。
方法 | 描述 |
---|---|
void park(): | 阻塞当前线程,如果调用unpark方法或者当前线程被中断,从能从park()方法中返回 |
void park(Object blocker) | 功能同方法1,入参增加一个Object对象,用来记录导致线程阻塞的阻塞对象,方便进行问题排查; |
void parkNanos(long nanos) | 阻塞当前线程,最长不超过nanos纳秒,增加了超时返回的特性; |
void parkNanos(Object blocker, long nanos) | 功能同方法3,入参增加一个Object对象,用来记录导致线程阻塞的阻塞对象,方便进行问题排查; |
void parkUntil(long deadline) | 阻塞当前线程,直到deadline; |
void parkUntil(Object blocker, long deadline) | 功能同方法5,入参增加一个Object对象,用来记录导致线程阻塞的阻塞对象,方便进行问题排查; |
同样的,有阻塞的方法,当然有唤醒的方法,什么呢?unpark(Thread) 方法。该方法可以将指定线程唤醒。
需要注意的是:park 方法和 unpark 方法执行顺序不是那么的严格。比如我们在 Thread 类中提到的 suspend 方法 和resume 方法,如果顺序错误,将导致永远无法唤醒,但 park 方法和 unpark 方法则不会,因为 LockSupport 使用了类似信号量的机制。他为每一个线程准备了一个许可(默认不可用),如果许可能用,那么 park 函数会立即返回,并且消费这个许可(也就是将许可变为不可用),如果许可不可用,将会阻塞。而 unpark 方法则使得一个许可变为可用
14. AQS
AQS 为 AbstractQueuedSynchronizer 的简称
AQS是JDK下提供的一套用于实现基于FIFO等待队列的阻塞锁和相关的同步器的一个同步框架。
这个抽象类被设计为作为一些可用原子int值来表示状态的同步器的基类。
AQS管理一个关于状态信息的单一整数,该整数可以表现任何状态。
#比如
Semaphore 用它来表现剩余的许可数,
ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁;
FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)
- 使用须知
Usage
To use this class as the basis of a synchronizer, redefine the following methods, as applicable, by inspecting and/or modifying the synchronization state using {@link #getState}, {@link #setState} and/or {@link #compareAndSetState}:
- {@link #tryAcquire}
- {@link #tryRelease}
- {@link #tryAcquireShared}
- {@link #tryReleaseShared}>
- {@link #isHeldExclusively}
以上方法不需要全部实现,根据获取的锁的种类可以选择实现不同的方法:
支持独占(排他)获取锁的同步器应该实现tryAcquire、 tryRelease、isHeldExclusively;
支持共享获取锁的同步器应该实现tryAcquireShared、tryReleaseShared、isHeldExclusively。
- AQS浅析
AQS的实现主要在于维护一个"volatile int state"(代表共享资源)和
一个FIFO线程等待队列(多线程争用资源被阻塞时会进入此队列)。
队列中的每个节点是对线程的一个封装,包含线程基本信息,状态,等待的资源类型等。#state的访问方式有三种:
getState()
setState()
compareAndSetState()#AQS定义两种资源共享方式
Exclusive(独占,只有一个线程能执行,如ReentrantLock)
Share(共享,多个线程可同时执行,如Semaphore/CountDownLatch)
不同的自定义同步器争用共享资源的方式也不同。
自定义同步器在实现时只需要实现共享资源state的获取与释放方式即可,
至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等),AQS已经在顶层实现好了。
自定义同步器实现时主要实现以下几种方法:
isHeldExclusively():该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int):独占方式。尝试获取资源,成功则返回true,失败则返回false。
tryRelease(int):独占方式。尝试释放资源,成功则返回true,失败则返回false。
tryAcquireShared(int):共享方式。尝试获取资源。负数表示失败;0表示成功,但没有剩余可用资源;正数表示成功,且有剩余资源。tryReleaseShared(int):共享方式。尝试释放资源,如果释放后允许唤醒后续等待结点返回true,否则返回false。
以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()函数返回,继续后余动作。
一般来说,自定义同步器要么是独占方法,要么是共享方式,
他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种即可。
但AQS也支持自定义同步器同时实现独占和共享两种方式,如"ReentrantReadWriteLock"。
15. 锁基本概念
- 公平锁/非公平锁
- 可重入锁
- 独享锁/共享锁
- 互斥锁/读写锁
- 乐观锁/悲观锁
- 分段锁
- 偏向锁/轻量级锁/重量级锁
- 自旋锁
- 公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序,
有可能后申请的线程比先申请的线程优先获取锁;
有可能会造成优先级反转或者饥饿现象。
对于Java ReentrantLock而言,通过构造函数指定该锁是否是公平锁,默认是非公平锁。
非公平锁的优点在于吞吐量比公平锁大。
对于Synchronized而言,也是一种非公平锁。
由于其并不像ReentrantLock是通过AQS的来实现线程调度,
所以并没有任何办法使其变成公平锁。
- 可重入锁
可重入锁又名递归锁,是指在同一个线程在外层方法获取锁的时候,在进入内层方法会自动获取锁。
ReentrantLock, Synchronized都是可重入锁。
可重入锁的一个好处是可一定程度避免死锁
- 独享(排他)锁/共享锁
独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。
对于ReentrantLock而言,其是独享锁。
但是对于Lock的另一个实现类ReadWriteLock,其读锁是共享锁,其写锁是独享锁。
读锁的共享锁可保证并发读是非常高效的,读写,写读 ,写写的过程是互斥的。
独享锁与共享锁也是通过AQS来实现的,通过实现不同的方法,来实现独享或者共享。
对于Synchronized而言,当然是独享锁。
- 互斥锁/读写锁
上面讲的独享锁/共享锁就是一种广义的说法,互斥锁/读写锁就是具体的实现。
互斥锁在Java中的具体实现就是ReentrantLock
读写锁在Java中的具体实现就是ReadWriteLock
- 乐观锁/悲观锁
乐观锁与悲观锁不是指具体的什么类型的锁,而是指看待并发同步的角度。
悲观锁 (Synchronized 和 ReentrantLock)
认为对于同一个数据的并发操作,一定是会发生修改的,哪怕没有修改,也会认为修改。
因此对于同一个数据的并发操作,悲观锁采取加锁的形式。
悲观的认为,不加锁的并发操作一定会出问题。
乐观锁 (java.util.concurrent.atomic包)
认为对于同一个数据的并发操作,是不会发生修改的。
在更新数据的时候,会采用尝试更新,不断重新的方式更新数据。
乐观的认为,不加锁的并发操作是没有事情的。
悲观锁适合写操作非常多的场景,乐观锁适合读操作非常多的场景,
不加锁会带来大量的性能提升。
悲观锁在Java中的使用,就是利用各种锁。
乐观锁在Java中的使用,是无锁编程,常常采用的是CAS算法。
典型的例子就是原子类,通过CAS自旋实现原子操作的更新。
- 分段锁
分段锁其实是一种锁的设计,并不是具体的一种锁,ConcurrentHashMap并发的实现就是通过分段锁的形式来实现高效的并发操作。
ConcurrentHashMap中的分段锁称为Segment,
它类似于HashMap(JDK7与JDK8中HashMap的实现)的结构,
即内部拥有一个Entry数组,数组中的每个元素又是一个链表;
同时又是一个ReentrantLock(Segment继承了ReentrantLock)。
当需要put元素的时候,并不是对整个hashmap进行加锁,
而是先通过hashcode来知道他要放在那一个分段中,然后对这个分段进行加锁,
所以当多线程put的时候,只要不是放在一个分段中,就实现了真正的并行的插入。
但是,在统计size的时候,可就是获取hashmap全局信息的时候,就需要获取所有的分段锁才能统计。
分段锁的设计目的是细化锁的粒度,当操作不需要更新整个数组的时候,
就仅仅针对数组中的一项进行加锁操作。
- 偏向锁/轻量级锁/重量级锁
这三种锁是指锁的状态,并且是针对Synchronized。
在Java 5通过引入锁升级的机制来实现高效Synchronized。
这三种锁的状态是通过对象监视器在对象头中的字段来表明的。
偏向锁
是指一段同步代码一直被一个线程所访问,那么该线程会自动获取锁。降低获取锁的代价。
轻量级锁
是指当锁是偏向锁的时候,被另一个线程所访问,偏向锁就会升级为轻量级锁,
其他线程会通过自旋的形式尝试获取锁,不会阻塞,提高性能。
重量级锁
是指当锁为轻量级锁的时候,另一个线程虽然是自旋,但自旋不会一直持续下去,
当自旋一定次数的时候,还没有获取到锁,就会进入阻塞,该锁膨胀为重量级锁。
重量级锁会让其他申请的线程进入阻塞,性能降低。
- 自旋锁
在Java中,自旋锁是指尝试获取锁的线程不会立即阻塞,而是采用循环的方式去尝试获取锁,
这样的好处是减少线程上下文切换的消耗,缺点是循环会消耗CPU。
典型的自旋锁实现的例子,可以参考自旋锁的实现