Java 并发 学习笔记

并发

最近重新复习了一边并发的知识,发现自己之前对于并发的了解只是皮毛。这里总结以下Java并发需要掌握的点。

使用并发的一个重要原因是提高执行效率。由于I/O等情况阻塞,单个任务并不能充分利用CPU时间。所以在单处理器的机器上也应该使用并发。
为了实现并发,操作系统层面提供了多进程。但是进程的数量和开销都有限制,并且多个进程之间的数据共享比较麻烦。另一种比较轻量的并发实现是使用线程,一个进程可以包含多个线程。线程在进程中没有数量限制, 数据共享相对简单。线程的支持跟语言是有关系的。Java 语言中支持多线程。

Java 中的多线程是抢占式的。这意味着一个任务随时可能中断并切换到其它任务。所以我们需要在代码中足够的谨慎,防范好这种切换带来的副作用。

基础

Runnable 它可以理解成一个任务。它的run()方法就是任务的逻辑,执行顺序。

Thread 它是一个任务的载体,虚拟机通过它来分配任务执行的时间片。
Thread中的start方法可以作为一个并发任务的入口。不通过start方法来执行任务,那么run方法就只是一个普通的方法

线程的状态有四种:

  1. NEW 线程创建的时候短暂的处于这种状态。这种状态下已经可以获得CPU时间了,随后可能进入RUNNABLE,BLOCKED状态。
  2. RUNNABLE 此状态下只要CPU将时间分配给线程,线程中的任务就可以执行。随后可能进入BLOCKED,DEAD状态。
  3. BLOCKED 线程可以运行,但是有某个条件阻止着它。当线程处于阻塞状态时,CPU不会分配时间片给它,直到它重新进入RUNNABLE状态。
  4. DEAD 此状态的线程将永远不会获得CPU时间片。通常是因为run()方法返回才会到达此状态。此时任务还是可以被中断的。

Callable<T> 它是一个带返回的异步任务,返回的结果放到一个Future对象中。

Future<T> 它可以接受Callable任务的返回结果。在任务没有返回的时候调用get方法会阻塞当前线程。cancel方法会尝试取消未完成的任务(未执行->直接不执行,已经完成->返回false,正在执行->尝试中断)。

FutureTask<T> 同时继承了Runnable, Callable 接口。

Java 1.5之后,不再推荐直接使用Thread对象作为任务的入口。推荐使用Executor管理Thread对象。Executor是线程与任务之间的的一个中间层,它屏蔽了线程的生命周期,不再需要显式的管理线程。并且ThreadPoolExecutor 实现了此接口,我们可以通过它来利用线程池的优点。

线程池涉及到的类有:Executor, ExecutorService, ThreadExecutorPool, Executors, FixedThreadPool, CachedThreadPool, SingleThreadPool

Executor 只有一个方法,execute来提交一个任务

ExecutorService 提供了管理异步任务的方法,也可以产生一个Future对象来跟踪一个异步任务。

主要的方法如下:

  • submit 可以提交一个任务
  • shutdown 可以拒绝接受新任务
  • shutdownNow 可以拒绝新任务并向正在执行的任务发出中断信号
  • invokeXXX 批量执行任务

ThreadPoolExecutor 线程池的具体实现类。线程池的好处在于提高效率,能避免频繁申请/回收线程带来的开销。

它的使用方法复杂一些,构造线程池的可选参数有:

  1. corePoolSize : int 工作的Worker的数量。
  2. maximumPoolSize : int 线程池中持有的Worker的最大数量
  3. keepAliveTime : long 当超过Workder的数量corePoolSize的时候,如果没有新的任务提交,超过corePoolSize的Worker的最长等待时间。超过这个时间之后,一部分Worker将被回收。
  4. unit : TimeUnit keepAliveTime的单位
  5. workQueue : BlockingQueue 缓存任务的队列, 这个队列只缓存提交的Runnable任务。
  6. threadFactory : ThreadFactory 产生线程的“工厂”
  7. handler : RejectedExecutionHandler 当一个任务被提交的时候,如果所有Worker都在工作并且超过了缓存队列的容量的时候。会交给这个Handler处理。Java 中提供了几种默认的实现,AbortPolicy, CallerRunsPolicy, DiscardOldestPolicy, DiscardPolicy。

这里的Worker可以理解为一个线程。

这里之前想不通,觉得线程不可能重新利用绑定新任务。看了下源码发现原来确实不是重新绑定任务。每一个Worker的核心部分只是一个循环,不断从缓存队列中取任务执行。这样达到了重用的效果。

final void runWorker(Worker w) {
    Runnable task = w.firstTask;
    // ...
    try {
        while(task != null || (task=getTask())!=null) {
            try{
                task.run();
            } catch(Exception e){
            }
            // ...
        }
    } finally {
        // ...
    }
    // ...
}

Executors类提供了几种默认线程池的实现方式。

  1. CachedThreadExecutor 工作线程的数量没有上限(Integer的最大值), 有需要就创建新线程。
  2. FixedThreadExecutor 预先一次分配固定数量的线程,之后不再需要创建新线程。
  3. SingleThreadExecutor 只有一个线程的线程池。如果提交了多个任务,那么这些人物将排队,每个任务都在上一个人物执行完之后执行。所有任务都是按照它们的提交顺序执行的。

sleep(long) 当前线程 中止 一段时间。它不会释放锁。Java1.5之后提供了更加灵活的版本。

TimeUnit 可以指定睡眠的时间单位。

优先级 绝大多数情况下我们都应该使用默认的优先级。不同的虚拟机中对应的优先级级别的总数,一般用三个就可以了 MAX_PRIORITY, NORM_PRIORITY, MIN_PRIORITY

让步 Thread.yield()建议相同优先级的其它线程先运行,但是不保证一定运行其它线程。

后台线程 一个进程中的所有非后台线程都终止的时候整个进程也就终止,同时杀死所有后台线程。与优先级没有什么关系。

join() 线程 A 持有线程T,当在线程T调用T.join()之后,A会阻塞,直到T的任务结束。可以加一个超时参数,这样在超时之后线程A可以放弃等待继续执行任务。

捕获异常 不能跨线程捕获异常。比如说不能在main线程中添加try-catch块来捕获其它线程中抛出的异常。每一个Thread对象都可以设置一个UncaughtExceptionHandler对象来处理本线程中抛出的异常。线程池中可以通过参数ThreadFactory来为每一个线程设置一个UncaughtExceptionHandler对象。

访问共享资源

在处理并发的时候,将变量设置为private非常的重要,这可以防止其它线程直接访问变量。

synchronized 修饰方法在不加参数情况下,使用对象本身作为锁。静态方法使用Class对象作为锁。同一个任务可以多次获得对象锁。

显式锁 Lock,相比synchronized更加灵活。但是需要的代码更多,编写出错的可能性也更高。只有在解决特殊问题或者提高效率的时候才用它。

原子性 原子操作就是永远不会被线程切换中断的操作。很多看似原子的操作都是非原子的,比如说long,double是由两个byte表示的,它们的所有操作都是非原子的。所以,涉及到并发异常的地方都加上同步吧。除非你对虚拟机十分的了解。

volatile 这个关键字的作用在于防止多线程环境下读取变量的脏数据。这个关键字在c语言中也有,作用是相同的。

原子类 AtomicXXX类,它们能够保证对数据的操作是满足原子性的。这些类可以用来优化多线程的执行效率,减少锁的使用。然而,使用难度还是比较高的。

临界区 synchronized关键字的用法。不是修饰整个方法,而是修饰一个代码块。它的作用在于尽量利用并发的效率,减少同步控制的区域。

ThreadLocal 这个概念与同步的概念不同。它是给每一个线程都创建一个变量的副本,并保持副本之间相互独立,互不干扰。所以各个线程操作自己的副本,不会产生冲突。

终结任务

这里我讲一下自己当前的理解。

一个线程不是可以随便中断的。即使我们给线程设置了中断状态,它也还是可以获得CPU时间片的。只有因为sleep()方法而阻塞的线程可以立即收到InterruptedException异常,所以在sleep中断任务的情况下可以直接使用try-catch跳出任务。其它情况下,均需要通过判断线程状态来判断是否需要跳出任务(Thread.interrupted()方法)。

synchronized方法修饰的代码不会在收到中断信号后立即中断。ReentrantLock锁控制的同步代码可以通过InterruptException中断。

Thread.interrupted方法调用一次之后会立即清空中断状态。可以自己用变量保存状态。

线程协作

wait/notifyAll wait/notifyAll是Object类中的方法。调用wait/notifyAll方法的对象是互斥对象。因为Java中所有的Object都可以做互斥量(synchronized关键字的参数),所以wait/notify方法是在Object类中的。

wait与sleep 不同在于sleep方法是Thread类中的方法,调用它的时候不会释放锁;wait方法是Object类中的方法,调用它的时候会释放锁。

调用wait方法之前,当前线程必须持有这段逻辑的锁。否则会抛出异常,不能继续执行。

wait方法可以将当前线程放入等待集合中,并释放当前线程持有的锁。此后,该线程不会接收到CPU的调度,并进入休眠状态。有四种情况肯能打破这种状态:

  1. 有其它线程在此互斥对象上调用了notify方法,并且刚好选中了这个线程被唤醒;
  2. 有其它线程在此互斥对象上调用了notifyAll方法;
  3. 其它线程向此线程发出了中断信号;
  4. 等待时间超过了参数设置的时间。

线程一旦被唤醒之后,它会像正常线程一样等待之前持有的所有锁。直到恢复到wait方法调用之前的状态。

还有一种不常见的情况,spurious wakeup(虚假唤醒)。就是在没有notify,notifyAll,interrupt的时候线程自动醒来。查了一些资料并没有弄清楚是为什么。不过为了防止这种现象,我们要在wait的条件上加一层循环。

当一个线程调用wait方法之后,其它线程调用该线程的interrupt方法。该线程会唤醒,并尝试恢复之前的状态。当状态恢复之后,该线程会抛出一个异常。

notify 唤醒一个等待此对象的线程。
notifyAll 唤醒所有等待此对象的线程。

错失的信号

当两个线程使用notify/wait或者notifyAll/wait进行协作的时候,不恰当的使用它们可能会导致一些信号丢失。例子:

T1:
synchronized(shareMonitor){
    // set up condition for T2
    shareMonitor.notify();
}

T2:
while(someCondition){
    // Point 1
    synchronized(shareMonitor){
        shareMonitor.wait();
    }
}

信号丢失是这样发生的:

当T2执行到Point1的时候,线程调度器将工作线程从T2切换到T1。T1完成T2条件的设置工作之后,线程调度器将工作线程从T1切换回T2。虽然T2线程等待的条件已经满足,但还是会被挂起。

解决的方法比较简单:

T2:
synchronized(sharedMonitor) {
    while(someCondition) {
        sharedMonitor.wait();
    }
}

将竞争条件放到while循环的外面即可。在进入while循环之后,在没有调用wait方法释放锁之前,将不会进入到T1线程造成信号丢失。

notify & notifyAll 前面已经提过这两个方法的区别。notify是随机唤醒一个等待此锁的线程,notifyAll是唤醒所有等待此锁的线程。

Condition 他是concurrent类库中显式的挂起/唤醒任务的工具。它是真正的锁(Lock)对象产生的一个对象。其实用法跟wait/notify是一致的。await挂起任务,signalAll()唤醒任务。

生产者消费者队列 Java中提供了一种非常简便的容器,BlockingQueue。已经帮你写好了阻塞式的队列。

除了BlockingQueue,使用PipedWriter/PipedReader也可以方便的在线程之间传递数据。

死锁

死锁有四个必要条件,打破一个即可去除死锁。

四个必要条件:

  1. 互斥条件。 互斥条件:一个资源每次只能被一个进程使用。
  2. 请求与保持条件:一个线程因请求资源而阻塞时,对已获得的资源保持不放。
  3. 不剥夺条件:线程已获得的资源,在末使用完之前,不能强行剥夺。
  4. 循环等待条件:若干线程之间形成一种头尾相接的循环等待资源关系。

本来自己翻译,但发现百度上描述的更好一些,直接copy到这里来,并把进程换成了线程。

其它工具

CountDownLatch 同步多个任务,强制等待其它任务完成。它有两个重要方法countDown,await以及构造时传入的参数SIZE。当一个线程调用await方法的时候会挂起,直到该对象收到SIZE次countDown。一个对象只能使用一次。

CyclicBarrier 也是有一个SIZE参数。当有SIZE个线程调用await的时候,全部线程都会被唤醒。可以理解为所有运动员就位后才能起跑,早就位的运动员只能挂起等待。它可以重复利用。

DelayQueue 一个无界的BlockingQueue,用来放置实现了Delay接口的对象,在队列中的对象只有在到期之后才能被取走。如果没有任何对象到期,就没有头元素。

PriorityBlockingQueue 一种自带优先级的阻塞式队列。

ScheduledExecutor 可以把它想象成一种线程池式的Timer, TimerTask。

Semaphore 互斥锁只允许一个线程访问资源,但是Semaphore允许SIZE个线程同时访问资源。

Exchanger 生产者消费者问题的特殊版。两个线程可以在都‘准备好了’之后交换一个对象的控制权。

ReadWriteLock 读写锁。 读-读不互斥,读-写互斥,写-写互斥。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容