Java多线程基础（一）——java线程状态与操作

1线程基本操作

1.1 创建线程
  • 1.继承java.lang.Thread
public class MyThread extends Thread {
    //复写run方法.
    public void run() {
       //...
    }
}
public class MultiThread {
    public static void main(String[] args) {
        MyThread t = new MyThread();
        //调用start 来 启动子线程
        t.start();   
        //主线程继续同时向下执行
        //...
    }
}
  • 2.实现java.lang.Runnable接口
//实现runable
public class MyThread implements Runnable {
    public void run() {
        //...
    }
}
public class MultiThread {
    public static void main(String[] args) {
        //Thread的构造参数为 Runable接口
        Thread t = new Thread(new MyThread());
        t.start();    //启动子线程
        //主线程继续同时向下执行
        //..
    }
}
1.2 线程的结束

主线程执行结束,子线程未结束,进程不退出,为何? 如果把子线程设置为 deamon Thread,则主线程退出,进程就退出了.

所有非deamon线程都退出时,进程才退出.

1.3 暂停线程

java.lang.Thread.sleep(xxx)方法（注意是类方法）。使当前正在执行的线程暂停指定的时间，如果线程持有锁，sleep方法并不会释放锁。

public class Main {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            System.out.print(i + " ");
            try {
                Thread.sleep(1000);    //当前main线程暂停1000ms
            } catch (InterruptedException e) {
            }
        }
    }
}

上述代码中，当main线程调用Thread.sleep(1000)后，线程会被暂停，如果被interrupt，则会抛出InterruptedException异常。

1.4 线程中断

java.lang.Thread#interrupt()方法
Thread实例方法。当被interrupt的线程处于waitting状态如wait、sleep、join时，会抛出InterruptedException异常,异常抛出后线程内的 中断状态被重置为false,所以捕获异常后,要及时退出线程.。
事实上，interrupt方法只是改变目标线程的中断状态（interrupt status），而那些会抛出InterruptedException异常的方法，如wait、sleep、join等，都是在方法内部不断地检查中断状态的值

java.lang.Thread#isInterrupted()方法
Thread实例方法：用来检查指定线程的中断状态。true为中断状态; false为: 非中断。

java.lang.Thread#interrupted方法
Thread类方法：返回调用此方法的线程的中断状态,并清除中断状态（置为false） ；

1.5 线程同步

synchronized 是管程,细节查看管程资料
synchronized 可使用 对象实例锁 和 类锁.

package com.rock.multithread.base;

public class SynchronizedDemo {

    /**
     * 实例方法锁 即 this 实例锁
     * @return
     */
    public synchronized String 实例方法锁(){
        return "";
    }

    /**
     * 同 this 实例锁
     * @return
     */
    public String this锁(){
        synchronized (this){
            return "";
        }
    }

    /**
     * 静态方法锁 即类锁
     * @return
     */
    public static synchronized String 静态方法锁(){
        return "";
    }

    /**
     * 类锁,同上
     * @return
     */
    public String 类方法锁(){
        synchronized (SynchronizedDemo.class){
            return  "";
        }
    }

}
1.6 线程协调

1Object#wait
放弃锁,等通知

  • 先进入同步代码块,即拿到锁
  • xxx.wait(); 把当前线程放入锁对象的wait set 中,释放锁;
  • 等待别的线程调用 通知方法 给信号后,刚执行wait的线程 从wait set 中移除,放入锁池队列中,被系统调度唤醒后重新持有锁,执行wait后的代码.
  • 通知方法 包括notify,notifyAll,interrupt
    ...

2.Object#notify / Object#notifyall
通知等待的线程

  • 先进入同步代码块,即拿到锁
  • notify / notifyall 给等待线程发信号,两者的区别是,notify方法 只从 wait set中移动一个线程到锁池中,notifyAll是 wait set中的全部线程都移到锁池中.
  • 继续执行notify/notifyAll 后的方法,直到退出同步代码块,才释放锁.这里是关键,发送通知后,线程不会立即终止执行,所以后续的代码可能还会修改竞态条件.

4.wait的使用为何要加while
1.案例1

public class WaitNotifyDemo {

    private volatile  boolean isEmpty= false;

    /**
     * 假唤醒实例1 ,提供消费条件,唤醒消费线程,又把消费条件给取消了,这样消费线程醒来,缺不满足条件.
     */
    public synchronized void fakeProvider1(){
        System.out.println("冒牌provider 把isEmpty 设置为true,通知后,还把信号再修改为false");
        isEmpty = true;
        notify();//发送通知后,线程不会退出
        isEmpty = false; //说不清的原因 信号又被重置了.这种情况下,consumer线程醒来后,其实isEmpty条件是不满足的,所以应该应用用while循环来判断条件
    }
    public synchronized void consumer1() throws InterruptedException {
        //使用while循环来防止假唤醒.所谓的假唤醒本质是,唤醒后不满足继续执行的条件,所以继续判断下条件是否满足,不满足就继续wait.
        while (isEmpty){
            //条件不满足,等待
            this.wait();
        }
        System.out.println("成功消费一次,isEmpty 设置为true");
        isEmpty = true;
    }
}

2.案例2

public class WaitNotifyDemo2 {

    private volatile  boolean isEmpty= false;
    /**
     * 一个provider
     * 多个线程执行消费
     * 正常的设置消费条件.发通知
     */
    public synchronized void provider(){
        System.out.println("provider 把isEmpty 设置为true,通知所有等待线程");
        isEmpty = true;
        notifyAll();
    }

    /**
     * 多个消费者都唤醒后,其中1个消费者拿到锁,执行消费后,把状态重置了.另外一个消费者的执行条件就不满足了,要继续等.
     * @throws InterruptedException
     */
    public synchronized void consumer() throws InterruptedException {
        //使用while循环来防止假唤醒.所谓的假唤醒本质是,唤醒后不满足继续执行的条件,所以继续判断下条件是否满足,不满足就继续wait.
        while (isEmpty){
            //条件不满足,等待
            this.wait();
        }
        System.out.println("成功消费一次,isEmpty 设置为true");
        isEmpty = true;
    }
}
1.6 线程让步

java.lang.Thread.yield()方法：线程让步 不会释放锁
线程执行了yield()方法后，就会进入Runnable(就绪状态)，【不同于sleep()和join（）方法，因为这两个方法是使线程进入阻塞状态】。除此之外，yield()方法还与线程优先级有关，当某个线程调用yield()方法时，就会从运行状态转换到就绪状态后，CPU从就绪状态线程队列中只会选择与该线程优先级相同或者更高优先级的线程去执行。

1.7 等待线程的结束

java.lang.Thread.join方法
实例方法.当前线程调用目标线程实例的join方法后,阻塞当前线程直到目标线程中run方法运行结束.

1.8 通用线程状态
image.png

这“五态模型”的详细情况如下所示。

  1. 初始状态，指的是线程已经被创建，但是还不允许分配CPU执行。这个状态属于编程语言特有的，不过这里所谓的被创建，仅仅是在编程语言层面被创建，而在操作系统层面，真正的线程还没有创建。
  2. 可运行状态，指的是线程可以分配CPU执行。在这种状态下，真正的操作系统线程已经被成功创建了，所以可以分配CPU执行。
  3. 当有空闲的CPU时，操作系统会将其分配给一个处于可运行状态的线程，被分配到CPU的线程的状态就转换成了运行状态。
  4. 运行状态的线程如果调用一个阻塞的API（例如以阻塞方式读文件）或者等待某个事件（例如条件变量），那么线程的状态就会转换到休眠状态，同时释放CPU使用权，休眠状态的线程永远没有机会获得CPU使用权。当等待的事件出现了，线程就会从休眠状态转换到可运行状态。
  5. 线程执行完或者出现异常就会进入终止状态，终止状态的线程不会切换到其他任何状态，进入终止状态也就意味着线程的生命周期结束了。
1.9 Java线程状态

Java语言里则把可运行状态和运行状态合并了，这两个状态在操作系统调度层面有用，而JVM层面不关心这两个状态，因为JVM把线程调度交给操作系统处理了。

Java语言里把休眠状态 细化为 BLOCKED（阻塞状态),WAITING（无时限等待）,TIMED_WAITING（有时限等待）
所以java线程状态为:


image.png
image.png

  1. NEW vs RUNNABLE
    new出来对象后,调用其start方法.

  2. RUNNABLE vs BLOCKED

  • 运行中(runnable)的线程等待synchronized的隐式锁 ,进入blocked状态,等到获得了synchronized的隐式锁后,进入runnable状态
  • 线程中执行阻塞式API的调用后 还是处于runnable状态

熟悉操作系统线程的生命周期的话，可能会有个疑问：线程调用阻塞式API时，是否会转换到BLOCKED状态呢？在操作系统层面，线程是会转换到休眠状态的，但是在JVM层面，Java线程的状态不会发生变化，也就是说Java线程的状态会依然保持RUNNABLE状态。JVM层面并不关心操作系统调度相关的状态，因为在JVM看来，等待CPU使用权（操作系统层面此时处于可执行状态）与等待I/O（操作系统层面此时处于休眠状态）没有区别，都是在等待某个资源，所以都归入了RUNNABLE状态。
平时所谓的Java在调用阻塞式API时，线程会阻塞，指的是操作系统线程的状态，并不是Java线程的状态

  1. RUNNABLE vs WAITING

  • 获得synchronized隐式锁的线程，调用无参数的Object.wait()方法。

  • 调用无参数的Thread.join()方法。其中的join()是一种线程同步方法，thread-A中执行thread-B.join();thread-A等待thread-B执行完，其状态会从RUNNABLE转换到WAITING。当线程thread-B执行完，thread-A又会从WAITING状态转换到RUNNABLE。

  • 调用LockSupport.park()方法。Java并发包中的锁，都是基于LockSupport实现的。调用LockSupport.park()方法，当前线程会阻塞，线程的状态会从RUNNABLE转换到WAITING。调用LockSupport.unpark(Thread thread)可唤醒目标线程，目标线程的状态又会从WAITING状态转换到RUNNABLE。

  1. RUNNABLE vs TIMED_WAITING
  • 调用带超时参数的Thread.sleep(long millis)方法；
  • 获得synchronized隐式锁的线程，调用带超时参数的Object.wait(long timeout)方法；
  • 调用带超时参数的Thread.join(long millis)方法；
  • 调用带超时参数的LockSupport.parkNanos(Object blocker, long deadline)方法；
  • 调用带超时参数的LockSupport.parkUntil(long deadline)方法。

TIMED_WAITING和WAITING状态的区别，仅仅是操作方法多了超时参数

  1. RUNNABLE vs TERMINATED
  • 线程执行完 run() 方法后，会自动转换到TERMINATED状态
  • 如果执行run()方法的时候异常抛出，也会导致线程终止
  • Thread#stop 已经标记为@Deprecated，不建议使用了。正确的姿势其实是调用interrupt()方法
  • stop()方法会真的杀死线程，不给线程喘息的机会，如果线程持有synchronized隐式锁，也不会释放，那其他线程就再也没机会获得synchronized隐式锁，这实在是太危险了。所以该方法就不建议使用了，类似的方法还有suspend() 和 resume()方法，这两个方法同样也都不建议使用了，所以这里也就不多介绍了
  • interrupt()方法仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。被interrupt的线程，是怎么收到通知的呢？一种是异常，另一种是主动检测。
  • 当线程A处于WAITING、TIMED_WAITING状态时，如果其他线程调用线程A的interrupt()方法，会使线程A返回到RUNNABLE状态，同时线程A的代码会触发InterruptedException异常。上面我们提到转换到WAITING、TIMED_WAITING状态的触发条件，都是调用了类似wait()、join()、sleep()这样的方法，我们看这些方法的签名，发现都会throws InterruptedException这个异常。这个异常的触发条件就是：其他线程调用了该线程的interrupt()方法。
  • 当线程A处于RUNNABLE状态时，并且阻塞在java.nio.channels.InterruptibleChannel上时，如果其他线程调用线程A的interrupt()方法，线程A会触发java.nio.channels.ClosedByInterruptException这个异常；而阻塞在java.nio.channels.Selector上时，如果其他线程调用线程A的interrupt()方法，线程A的java.nio.channels.Selector会立即返回。
  • 上面这两种情况属于被中断的线程通过异常的方式获得了通知。还有一种是主动检测，如果线程处于RUNNABLE状态，并且没有阻塞在某个I/O操作上，例如中断计算圆周率的线程A，这时就得依赖线程A主动检测中断状态了。如果其他线程调用线程A的interrupt()方法，那么线程A可以通过isInterrupted()方法，检测是不是自己被中断了。
Thread th = Thread.currentThread();
while(true) {
  if(th.isInterrupted()) {
    break;
  }
  // 省略业务代码无数
  try {
    Thread.sleep(100);
  }catch (InterruptedException e){
    //如果sleep方法抛出了此异常,表示被中断了,此处应该退出线程
    //若catch中不退出线程,因则应该应该重置一下中断标示，因为抛出异常后，中断标示会自动清除掉！
    Thread.currentThread().interrupt();
    e.printStackTrace();
  }
}
2.0 entry set vs wait set

参考管程之后这里就很清晰了.


image.png

锁对象有个 Entry Set 和 Wait Set 和当前持锁线程(The Owner)
WaitSet ：处于wait状态的线程，会被加入到wait set；
EntryList：处于等待锁block状态的线程，会被加入到entry set；
The Owner ：表示某一线程成功竞争到对象锁。

并发基本概念之 管程
Java多线程基础（一）——线程与锁
Java并发编程实战
JVM源码分析之Object.wait/notify实现

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 212,029评论 6赞 492
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 90,395评论 3赞 385
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 157,570评论 0赞 348
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 56,535评论 1赞 284
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 65,650评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,850评论 1赞 290
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,006评论 3赞 408
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 37,747评论 0赞 268
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,207评论 1赞 303
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,536评论 2赞 327
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,683评论 1赞 341
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,342评论 4赞 330
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,964评论 3赞 315
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,772评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,004评论 1赞 266
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 46,401评论 2赞 360
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 43,566评论 2赞 349