1、线程安全与锁
线程安全的本质,在于 存在了共享的可变状态 status, 在多线程共同操作状态变量时,当计算的正确性依赖于运行时相关的时序(比如i++,先取出i,再+1,然后赋值),就会出现竞争(竞态)
无状态对象永远是线程安全的.
所以线程安全 三步骤:a、无共享状态;b、共享状态不可变;c、共享状态同步
要做到状态同步,就必须要通过锁 or volatile;本章节先讨论锁,被锁保护的代码块可以认为是一间屋子,只有唯一的锁可以打开,即同时只能只有一个线程进入。其他进入的线程必须拿到这把锁。这样就保证了数据的安全性。
I、内部锁 synchronized
三种用法:a、锁住变量 (这个变量就是锁);b、锁住方法 (拥有这个方法的对象是锁) ;c、锁住静态方法 (这个类的Class对象是锁)
每个java对象都自带隐式锁(也称为监视器锁)
可重入 - 每个线程可以对同一个锁多次获取,比如 下面这个例子 a 获取一次,b还要再获取,获取时计数\退出时减少(像不像早期的垃圾回收)
public synchronized a(){
b();
}
public synchronized b(){
}
II、显式锁 ReentrantLock
ReentrantLock + Condition 替换了原先的 synchronized + object
Condition 实现了 资源的 竞争与释放 ; Lock 实现了 代码的隔离
Lock lock = new ReentrantLock();
Waits = lock.newConidition();
Lock.lock();
Try{
Waits.await() – 等同于 原先的锁wait
}finnaly{
Lock.unlock
}
显示锁有什么好处?
a、tryLock( xxx ) -- 可以设置超时,无法获取的时候,这样可以避免死锁
b、lockInterruptibly(); -- 可以响应中断的锁
c、性能提升? -- java6 以后的版本已经没有性能优势了
d、读写分离
显式锁里面,有专门的 ReentrantReadWriteLock 读写分离锁。好吧,这里又看到类似数据库的设计思路了。
读锁可以多线程同时进入,是共享的。写锁只能单线程进入,是排他的
e、公平
初始化 ReentrantLock 时,可以指定是否是公平的。何解? 因为线程调度唤醒线程时,是随机的,有可能先来的线程未获取到,这就不公平了。指定公平性,可以按等待顺序获取锁
有啥缺点?
每次都需要显式手工finnaly 关闭
内部锁 or 显式锁?
如何选择两者。jdk 推荐 默认使用 内部锁,因为简单、方便;如果有特殊需求的,如上显示锁描述的好处。
III、死锁
a、出现死锁的条件:
互斥 - 资源只能被一个线程占有
请求与保持 - 占住的不想放,想要的非要
不可剥夺 - 占住的不能抢走
循环等待 - 只要有人放手就解开了,就是没人放手
b、如果预防死锁?
排好队 - 如果非要获取多个锁,那所有的获取锁方式都要 按照一定顺序
中断(抢夺) - 显式锁可以中断某个锁
超时(放弃) - 显式锁可以设置超时放弃锁
c、如何检测死锁?
打印堆栈
win( Ctrl + Break ) linux (kill -3)
Jmap+jhat+jstatck
监视工具
JConsole | Visual VM
IV、使用锁的建议
a、如何选择内部锁和显式锁,默认内部锁,特殊情况比如定时、中断使用显式。(参见上文描述)
b、尽量减少同步的范围、 不要在 方法上加锁,而是在方法内部
c、多个锁按顺序获取,可以把获取的地方统一隔离,放在一起,通过对象hash值identityHashCode安排顺序
2、线程安全与对象(非阻塞式实现)
同步是 保护 对象(数据) 的一种方式,除了用锁这种同步方式,还有其他效率更高的方式。
I、volatile - 共享变量
系统会监视这个变量,对它的操作不会和其他内存操作重排序,也就是说对volatile 变量的操作当成是原子操作;所有的修改其他线程都可见,也就不需要加锁同步了。
volatile int a;
对volatile的使用有一些限制,主要是自增类的操作不能使用(比如i++)、只能单独使用、不能组合使用
II、CAS 与原子类型 -- CAS = 比较并设置CompareAndSet
实现思路很简单,就是当修改的值和 现在内存的值比较,如果一致了,就修改生效;如果不一致就一直循环检查,直到生效为止。
public final long getAndDecrement() {
while (true) {
long current = get();
long next = current - 1;
if (compareAndSet(current, next))
return current;
}
}
volatile和 CAS 都是CPU层面提供的底层技术,不是语言本身提供的技术,其中CAS的实现还需要调用 JNI 本地化实现。
volatile + CAS 构成了java的原子类型库 java\util\concurrent\atomic
a、基本类型的原子包装器 AtomicInteger | AtomicLong | AtomicBoolean
b、数组类型 AtomicIntegerArray ...
c、对象类型 AtomicReference (包装一个类) | 域更新器 AtomicReferenceFieldUpdater(利用反射,更细粒度的操作)
-- java自身的cocurrent类库也有使用原子类型的,比如ConcurrentLinkedQueue 就使用了 域更新器实现 具体链表 字段的更新
该如何选择 锁 or 原子类型+volatile?
一般需要用在控制变量、标记值等等应用场景应该选用 原子类型这些非阻塞的同步方式;如果有大段代码复杂逻辑需要保护,则采用同步方式。
III、封闭线程Ad-hoc 与ThreadLocal
把数据封闭在线程内部,就不存在共享状态的问题,也就是线程安全了,最典型的应用就是 ThreadLocal,网上对ThreadLocal很多理解都有误区
a、每个线程绑定一个 ThreadLocal.ThreadLocalMap 对象,线程内部的局部变量。
b、存放对象 set(T) 实际上就是 把 ThreadLocal 对象作为key ,T 作为value put 到 线程的map对象中
c、获取对象 get,实际上就是把 this自身的对象 作为key 从 线程map中取出数据
几个关键问题
a、多个线程的 ThreadLocal 对象虽然是同一个,但Map 是线程自己的,所以在调用 set get 时,获取的是自己Map存储的 value,实现了数据封闭
b、设置的value 必须是新的对象或者基本类型,否则如果设置的 是同一个 对象的引用的话,取出来还是同一个引用,就达到不到隔离的效果。
c、如果需要 在所有线程共享一个初始数据,可以 继承ThreadLocal,扩展实现 initialValue 方法,这样所有线程都能看到初始化数据
private static ThreadLocal<List<String>> threadLog = new ThreadLocal<List<String>>(){
protected List<String> initialValue(){
return new ArrayList<String>();
}
};
总结:ThreadLocal本质上是一个 空间换时间的 实现,通过在多个线程中 存储不同的拷贝,实现了线程安全
3、线程生命周期
I、五种状态
新建 - 两种方法创建多线程:继承java.lang.Thread,覆盖run方法 | 实现java.lang.Runnable接口,实现run方法
就绪 - Thread.start - 对应run 方法
运行 - 线程抢到CPU开始运行
阻塞 - 遇到 锁、休眠、IO等情况线程处于阻塞态 (等待、休眠)
终止 - 正常结束,被中断 Thread.interrrupt
II、改变状态
a、sleep - 当前线程休眠
b、yield - 当前线程让渡CPU给同级别的线程
c、wait - 阻塞等待其他资源的锁
d、join - 傻傻等其他线程结束后再结束
sleep vs wait
sleep 只是线程休眠,并不会释放占有的资源,wait会释放所有的资源;wait 是资源上的方法,而休眠是线程方法
sleep vs yield
sleep 线程切入休眠状态,等待一定时间才唤醒抢占CPU;yield 只是暂时让渡CPU
在构造函数中启动线程是危险的,因为可能构造函数还未构造完成,如果回调或者其他就会出现异常。避免在构造函数启动线程。
III、线程优先级
调度器根据线程优先级作为参考,决定多长时间调度该线程 ;Thread类中定义了默认3个级别 1 MIN ,5 NORMAL ,10 MAX
4、线程间通讯
严格来说 join 方法也算是一种线程间通讯,一个线程等待另一个线程处理结束,才继续。
线程间通讯,不像进程间通讯Socket、共享内存、系统级别信号量,线程间因为共享资源,所以通讯方式大都是通过共享的资源。
传统方式
I、经典通讯方式 wait/notify/notifyAll
使用wait/notify的正确姿势
线程A
synchronized(list){
while(list.size == 0)
list.wait();
}
线程B
synchronized(list){
list.add(xxx);
list.notifyAll();
}
a、wait 方法一般都要写在synchronized 的循环里
b、synchronized 锁住的对象和 wait的对象一般是同一个对象
c、使用notifyAll 而不是 notify
wait 有无参数? 有参数只是多了一个唤醒条件,唤醒后和wait一样继续抢占资源
notify 和 notifyAll ? notifyAll唤醒所有线程,只有一个线程抢到,notify只随机唤醒一个线程
线程屏障
II、闭锁 CountDownLatch 和 关卡 CyclicBarrier
a、从功能上看,两者很类似,都是用作阻塞的线程控制。
b、从语义上看,略有区别,闭锁等待的是事件、关卡等待的是线程,两者都是在await等待;闭锁通过 countDown 这个事件、触发等待的线程,而关卡需要互相等待、等所有线程处理完成后、触发等待的线程。
c、更大的区别则是:CountDownLatch的计数器只能使用一次。而CyclicBarrier的计数器可以使用reset() 方法重置。CyclicBarrier还提供其他有用的方法,比如getNumberWaiting方法可以获得阻塞的线程数量。isBroken方法用来知道阻塞的线程是否被中断。
III、信号量 Semaphore
和操作系统的信号量概念一样,允许一个资源被被操作使用的次数
Semaphore s = new Semaphore(100);
申请 s.acquire()
释放 s.release()
以上三种使用方法,wait/闭锁/信号量 某种程度上都属于资源申请;而闭锁,则是单纯的线程等待控制。下面介绍另一种方式,数据交换.
IV、Exchanger 数据交换
只能两个线程进行数据交换
Exchange<ExchangeData> exc = new Exchange<ExchangeData>();
A线程执行 IN = exc.exchange(OUT) ,此时A线程阻塞
B线程执行 OUT = exc.exchange(IN) ,此时A、线程解除阻塞,双方数据发生了交换
5、线程池
线程池一般有两种实现方式:一种是 任务池,各个线程循环去池里取任务;一种是 线程池,提交任务后,从池里取出空闲线程处理。
I、ThreadPoolExecutor
任务队列 BlockingQueue - 使用了阻塞队列作为提交的任务,接受继承 Runnable 的任务
线程池 HashSet<Worker> - 最少corePoolSize 最大 maximumPoolSize 空闲时间 keepAliveTime ;这三个参数决定 线程数目在 最小和最大之间弹性处理(当 > 最少,且 > 空闲时间,释放一部分空闲线程)
线程工厂ThreadFactory - 提供创建线程的方法 (还是为了扩展性, 给应用更多的创建线程前后的处理工作),Executors框架提供了一些线程工厂的实现
工作线程 Worker - 实现了Runnable ,绑定了一个线程(ThreadFactory 创建线程时,传入),执行提交的任务外,还有beforeExecute afterExecute 的钩子函数
队列管理
ThreadPoolExecutor 的队列管理是开放出来由外界提供 BlockingQueue的实现,具体参见下面 并发框架的 Executors 提供的一些默认队列
饱和策略
当有限队列充满后(即无法把任务提交到 BlockingQueue中去),就要有饱和策略。ThreadPoolExecutor的饱和策略,可以通过调用setRejectedExecutionHandler来修改
中止(abort)
遗弃(discard)
遗弃最旧的(discard-oldest)
调用者运行(caller-runs)
II、Executors/ExecutorServie(Executor) 框架
a、Executor 框架 -- 其实就是一个 Command模式
接口非常简单,把一个Runnable线程作为参数
void execute(Runnable command);
一般情况下,不需要自己定义一个线程,而是提交任务给Executor框架
b、ExecutorService 框架 -- Active Object 模式(主动对象模式)
调用线程 方法的调用 和被调用线程的 方法执行 进行解耦
被调用线程内部绑定一个 线程对象,即ThredPoolExecutor 的Worker,自己管理线程的状态
获取被调用线程的引用
ExecutorService service = Executors.newFixedThreadPool(NTHREADS);
提交
service.execute(task);
service.submit(task);
还可以管理executor的生命周期
service.shutdown();
c、队列
使用无限队列 LinkedBlockingQueue (对于ThreadPoolExecutor 来说这些队列都是有限的,可以把指定容量的队列给他,但Executors 默认的都是无限未指定容量的队列)
newFixedThreadPool -- 定长的线程池
newSingleThreadExecutor -- 单线程化的 executor
使用同步移交队列 SynchronousQueue (没有内存的队列,直接把队列从 提交者 给 消费者,据说等待性能更好?少了数据结构的操作开销?)
newCachedThreadPool -- 可缓存的线程池
周期线程池
newScheduledThreadPool - 定长线程池,支持定时和周期的任务执行
Timer和TimerTask 的改进版本
原先的Timer存在一些缺陷,Timer调度是基于绝对时间,对系统时间改变很敏感。(ScheduledThreadPoolExecutor 支持相对时间);所有timer任务在一个线程执行,如果耗时操作导致其他任务延迟,会出现一些不可预料的错误Timer中如果timetask执行失败,整个timer的任务都失败
// 定时器
public class Timer {
public static final int TIME_DEFAULT = 15 * 60;
protected ScheduledExecutorService service = Executors.newScheduledThreadPool(1);
protected int period;
protected Runnable runnable;
public Timer(Runnable runnable){
this(TIME_DEFAULT, runnable);
}
public Timer(int period, Runnable runnable){
this.period = period;
this.runnable = runnable;
}
public void start(){
service.scheduleAtFixedRate(runnable, 0, period, TimeUnit.SECONDS);
}
public void destroy(){
service.shutdown();
}
// 绝对定时器,从下一个粒度整点开始
public static class AbsoluteTimer extends Timer{
public AbsoluteTimer(Runnable runnable) {
super(runnable);
}
public AbsoluteTimer(int period, Runnable runnable) {
super(period, runnable);
}
@Override
public void start(){
service.scheduleAtFixedRate(runnable, Utils.getNextWholeTime(new Date(), period), period, TimeUnit.SECONDS);
}
}
}
d、线程工厂
DefaultThreadFactory
PrivilegedThreadFactory
III、任务管理
任务的执行,很容易操作,直接Thread 的start,或者提交到 任务执行框架 Executor执行
任务取消和停止,如何控制? 怎么知道任务执行的结果? 怎么隔离一个耗时任务 ?
取消的方法一:通过共享一个变量标志来进行任务的协调。- cancellation requested
中断的方法二:通过interrupt 中断方法,取消一个线程的执行
获取返回值
通过 局部变量,或者返回函数 -- 不可行,因为主线程和子线程并没有先后顺序的约束,受限于CPU、IO等复杂因素,结果是未知的
轮询 -- 可行,采用类似阻塞方式,不停的去检查是否完成,但多做了很多无用功,占用了CPU
回调 -- 正解
Future/FutureTask + Callable - 增强版的任务执行
Callable 提供 Runnable的增强功能 可以支持返回值
非阻塞的模型:Promise,Future 和 Callback 典型架构,Future 是异步执行方式
下面是一个简版的 任务执行框架,可以把任务提交给Executors框架,通过 Future 来
// 执行任务
static interface Function<Out>{
Out action() throws Exception ;
}
// 提交任务框架, 任何一次性执行的, 有可能延迟的都可以使用
private static <Out> Out submit(final Function<Out> in){
final ExecutorService exec = Executors.newSingleThreadExecutor();
Future<Out> future = exec.submit(new Callable<Out>(){
@Override
public Out call() throws Exception {
return in.action();
}
});
Out result = null;
try {
result = future.get(STREAM_TIMEOUT_PER_TIME, TimeUnit.SECONDS);
} catch (Exception e) {
log.error(String.format("Task Thread %d Get submit error : %s ", Thread.currentThread().getId(), e.getMessage()), e.getCause());
}finally{
exec.shutdown();
}
return result;
}
Fork/Join 框架?
IV、CompletionService:Executor 和 BlockingQueue的组合
整合了 Executor 和 BlockingQueue的功能。调用时,把Callable任务提交给他,同时像quue一样取出take和poll方法,返回的是一个Future
CompletionService 和 直接调用ExecutorService 区别在于,如果ExecutorService 启动多个任务,获取返回值时,多个Future需要管理起来,现在CompletionService直接用BlockingQueque对Future进行管理。
V、其他
线程增加 UncaughtExceptionHandler 捕获未知的线程异常,通知框架和应用
6、其他
JVM线程关闭 时,会有一个钩子函数
Runtime.getRuntime().addShutdownHook(new Thread(){
public void run(){
// 在这里做一些清理的工作。
}
});
守护线程 - 精灵线程 (dameon)
后台服务线程,和JVM线程同在
用户线程和守护线程区别不大,用户线程随时可以退出,守护线程一直到虚拟机的生命周期。 没有用户线程,守护线程和JVM一起退出。
一个完整的实际使用案例 - 这个可以用 JDK7的 Fork/Join 改写
// 下载调度线程
public class DownLoadTask {
public int MAX_THREAD ;
public int MAX_RECORD_PER_THREAD ;
public static final int DEFAULT_TIME_OUT = 120000;
private FileWriter writer;
private List<FileStruct> list;
private ExecutorService downPool ;
private PriorityBlockingQueue<SortFileData> container;
private CyclicBarrier oneTimes;
private AtomicInteger interrupt = new AtomicInteger(0);
private AtomicInteger timeout = new AtomicInteger(0);
private static Logger log = Logger.getLogger(DownLoadTask.class);
public DownLoadTask(List<FileStruct> list, FileWriter writer){
this.list = list;
this.writer = writer;
}
public void setMAX_THREAD(int MAX_THREAD) {
this.MAX_THREAD = MAX_THREAD;
}
public void setMAX_RECORD_PER_THREAD(int MAX_RECORD_PER_THREAD) {
this.MAX_RECORD_PER_THREAD = MAX_RECORD_PER_THREAD;
}
public void run(){
int ONE_SORT_TOTAL_NUM = MAX_THREAD * MAX_RECORD_PER_THREAD;
downPool = Executors.newFixedThreadPool(MAX_THREAD);
container = new PriorityBlockingQueue<SortFileData>(ONE_SORT_TOTAL_NUM);
int recordsSize = list.size();
int repeatCount = recordsSize / ONE_SORT_TOTAL_NUM;
int lastRecords = recordsSize % ONE_SORT_TOTAL_NUM;
int lastRecordsWorkerNum = (int) ceil((double)lastRecords / (double) MAX_RECORD_PER_THREAD);
int lastRecordsLastWorkNum = lastRecords % MAX_RECORD_PER_THREAD;
log.info("repeatCount size:"+ repeatCount);
log.info("lastRecords size:"+ lastRecords);
log.info("lastRecordsWorkerNum:"+ lastRecordsWorkerNum);
log.info("lastRecordsLastWorkNum:"+ lastRecordsLastWorkNum);
if(repeatCount==0){
oneTimes = new CyclicBarrier(lastRecordsWorkerNum + 1, new Combine());
}else if(repeatCount > 0){
oneTimes = new CyclicBarrier(MAX_THREAD + 1, new Combine());
}
int i = 0;
int count = 0;
int index = 0;
List<SortFileData> listfile = new ArrayList<SortFileData>();
for(int j=0;j<list.size();j++){
SortFileData sortfile = new SortFileData();
sortfile.setFilestruct(list.get(j));
sortfile.setIndex(j);
listfile.add(sortfile);
i++;
if(listfile.size()== MAX_RECORD_PER_THREAD){
downPool.submit(new Worker(index, listfile));
index++;
if(i % ONE_SORT_TOTAL_NUM == 0 ){
count++;
waitForComplete();
if(count == repeatCount && lastRecords != 0){
oneTimes = new CyclicBarrier(lastRecordsWorkerNum + 1, new Combine());
}
}
listfile = new ArrayList<SortFileData>();
}
}
if (lastRecordsLastWorkNum>0){
downPool.submit(new Worker(index, listfile));
}
if(lastRecordsWorkerNum != 0){
waitForComplete();
}
log.info(String.format("result [interrup = %d, timeout = %d]", interrupt.get(), timeout.get()));
}
// 线程阻塞
public void waitForComplete(){
try {
oneTimes.await(DEFAULT_TIME_OUT, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
log.error("Thread interrupted.", e.getCause());
interrupt.incrementAndGet();
} catch (BrokenBarrierException e) {
log.info("CyclicBarrier reset", e.getCause());
} catch (TimeoutException e) {
log.error("Thread timeout.", e.getCause());
timeout.incrementAndGet();
}
}
// 用于排序的查询结果
static class SortFileData implements Comparable<SortFileData>{
int index;
byte[] data;
private FileStruct filestruct;
public void setIndex(int index) {
this.index = index;
}
public void setData(byte[] data) {
this.data = data;
}
public FileStruct getFilestruct() {
return filestruct;
}
public int getIndex(){
return index;
}
public byte[] getData(){
return data;
}
public void setFilestruct(FileStruct filestruct) {
this.filestruct = filestruct;
}
@Override
public int compareTo(SortFileData o) {
SortFileData that = o;
if(this.getIndex() > that.getIndex()) return 1;
else if(this.getIndex() < that.getIndex()) return -1;
return 0;
}
}
//工作线程
class Worker implements Runnable{
private FileStruct struct;
private int index;
private List<SortFileData> listfile;
private DsuQuery query;
Worker(int index, List<SortFileData> listfile){
this.index = index;
this.listfile = listfile;
}
public void setQuery(DsuQuery query) {
this.query = query;
}
@Override
public void run() {
query = new DsuQuery();
for (SortFileData file:listfile) {
byte[] data = Decode.decode(query.queryOnce(file.getFilestruct()),file.getFilestruct());
//byte[] data =new byte[0];
file.setData(data);
container.offer(file);
}
waitForComplete();
}
}
//合并线程,取出数据,并合并写入文件
class Combine implements Runnable{
@Override
public void run() {
log.info("container size is "+ container.size());
while(!container.isEmpty()){
SortFileData result = container.poll();
writer.write(result.data);
//log.info("start write size is "+ result.data.length);
}
oneTimes.reset();
}
}
public static void main(String[] args) throws IOException {
List<FileStruct> list = new ArrayList<FileStruct>();
for(int i = 0 ; i < 14; i++){
FileStruct f = new FileStruct();
f.fileName = "test";
f.start = i;
f.length = 1;
f.timestab=i;
list.add(f);
}
LocalFileWriter filewriter = new LocalFileWriter(1);
DownLoadTask down=new DownLoadTask(list,filewriter);
down.run();
filewriter.close();
}
}