并发编程之Thread

并发编程之Thread

概述

对之前写的线程Thread的不足之处进行补充。

一、线程状态

线程在运行过程中，会存在几种不同的状态，一般来说，在Java中，线程的状态一共是6种状态，分别是：

• NEW：初始状态，线程被构建，但是还没有调用start方法
• RUNNABLED：运行状态，JAVA线程把操作系统中的就绪和运行两种状态统一称为“运行中”
• WAITING: 等待状态
• TIME_WAITING：超时等待状态，超时以后自动返回
• BLOCKED：阻塞状态，表示线程进入等待状态,也就是线程因为某种原因放弃了CPU使用权。
  阻塞也分为几种情况：
  • 等待阻塞：运行的线程执行wait方法，jvm会把当前线程放入到等待队列
  • 同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁被其他线程锁占用了，那么jvm会把当前的线程放入到锁池中
  • 其他阻塞：运行的线程执行Thread.sleep或者t.join方法，或者发出了I/O请求时，JVM会把当前线程设置为阻塞状态，当sleep结束、join线程终止、io处理完毕则线程恢复
• TERMINATED：终止状态，表示当前线程执行完毕

二、线程的终止

Thread提供了线程的一些操作方法，比如stop、suspend等，这些方法可以终止一个线程或者挂起一个线程，但是这些方法都不建议大家使用，因为线程的任务执行被强制中断，这种行为类似于在linux系统中执行 kill -9类似，它是一种不安全的操作。

Thread本质上就是执行这个线程的run方法。那么如果这个线程在run方法执行完之前，一直处于运行状态，直到run方法中的指令执行完毕，那么这个线程就会被销毁。

在正常情况下，这个线程是不需要人为干预去结束的，但是在一些特殊场景下线程的中断需要外部干预，例如：

• 线程中存在无限循环执行，比如while(true)循环
• 线程中存在一些阻塞的操作，比如sleep、wait、join等。

如果需要外部干预时，我们一般使用状态位来进行判断。

• 把while(true)改成while(flag)，这个flag可以作为共享变量被外部修改，修改之后使得循环条件无法被满足，从而退出循环并且结束线程。
• Java提供了一个 interrupt 方法，这个方法就是实现线程中断操作的

 
public class InterruptExample {

    private static class MyThread1 extends Thread {
        @Override
        public void run() {
            try {
                Thread.sleep(2000);
                System.out.println("Thread run");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

public static void main(String[] args) throws InterruptedException {
    Thread thread1 = new MyThread1();
    thread1.start();
    thread1.interrupt();
    System.out.println("Main run");
}

 
Main run
java.lang.InterruptedException: sleep interrupted
    at java.lang.Thread.sleep(Native Method)
    at InterruptExample.lambda$main$0(InterruptExample.java:5)
    at InterruptExample$$Lambda$1/713338599.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:745)
  

//默认情况下isInterrupted返回false、通过thread.interrupt变成了true
while(!Thread.currentThread().isInterrupted())

通常在线程中使用的sleep、wait、join等操作，它都会抛出一个InterruptedException异常，为什么会抛出异常？
是因为它在阻塞期间，必须要能够响应被其他线程发起中断请求之后的一个响应，而这个响应是通过InterruptedException来体现的。

但是这里需要注意的是，在这个异常中如果不做任何处理的话，我们是无法去中断线程的，因为当前的异常只是响应了外部对于这个线程的中断命令，同时，线程的中断状态也会复位，如果需要中断，则还需要在catch中添加下面的代码

while(!Thread.currentThread().isInterrupted()){

    try {
         TimeUnit.SECONDS.sleep(100);
        } catch (InterruptedException e) {
         e.printStackTrace();
        Thread.currentThread().interrupt(); //再次中断
       }
}

所以，InterruptedException异常的抛出并不意味着线程必须终止，而是提醒当前线程有中断的操作发生，至于接下来怎么处理取决于线程本身

1. 直接捕获异常不做任何处理
2. 将异常往外抛出
3. 停止当前线程，并打印异常信息

最后总结，关于 interrupt()、 interrupted()、isInterrupted()这三个方法，

• interrupt()是给线程设置中断状态并不实际中断线程执行；
• interrupted()是检测中断并清除中断状态（复位）；
• isInterrupted()只查询中断状态。
• 重要的一点就是interrupted()作用于当前线程，interrupt()和isInterrupted()作用于实例所代表的线程。

三、Thread Dump日志分析

1、CPU占用率不高，但响应很慢

1. 通过 jps 命令，查看java进程的pid
2. 通过`jstack 查看线程日志

如果存在死锁情况，Thread Dump日志里面肯定会给出Found one Java-level deadlock:信息。只要找到这个信息就可以立马定位到问题并且去解决。

Found one Java-level deadlock:
=============================
"Thread-1":
waiting to lock monitor 0x0000000026070c88 (object 0x00000007163b7d78, a
java.lang.Integer),
which is held by "Thread-0"
"Thread-0":
waiting to lock monitor 0x00000000260735c8 (object 0x0000000716649aa8, a
java.lang.Integer),
which is held by "Thread-1"

2、CPU占用率很高，响应很慢

生产中有的时候我们会发现CPU占用率很高，系统日志也看不出问题，那么这种情况下，我们需要去看一下运行中的线程有没有异常。

1. 通过 top -c 动态显示进程及占用资源的排行榜，从而找到占用CPU最高的进程PID，得到的 PID=80972
2. 然后再定位到对应的线程， top -H -p 80972 查找到该进程中最消耗CPU的线程，得到PID=81122

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
80972 root 20 0 7773456 296124 12904 S 100.2 1.8 0:38.83 java

3. 通过 printf “0x%x\n” 81122 命令，把对应的线程PID转化为16进制 0x13ce2
4. 执行这个命令 jstack 80972 | grep -A 20 0x13ce2 查看线程Dump日志，其中-A 20表示展示20行， 80972表示进程ID， 0x13ce2表示线程ID

[root@localhost test]# jstack 80972 | grep -A 20 0x13ce2
"Thread-3" #30 daemon prio=5 os_prio=0 tid=0x00007f84500ce000 nid=0x13ce2
runnable [0x00007f84a78f7000]
java.lang.Thread.State: RUNNABLE
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
- locked <0x00000006c812f1b0> (a java.io.BufferedOutputStream)
at java.io.PrintStream.write(PrintStream.java:482)
- locked <0x00000006c812f190> (a java.io.PrintStream)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
- locked <0x00000006c812f2d0> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
at java.io.PrintStream.newLine(PrintStream.java:546)
- eliminated <0x00000006c812f190> (a java.io.PrintStream)
at java.io.PrintStream.println(PrintStream.java:807)
- locked <0x00000006c812f190> (a java.io.PrintStream)
at com.example.threaddemo.WhileThread.run(ThreadController.java:33)
at java.lang.Thread.run(Thread.java:748)

可以发现是WhileThread.run方法中，执行的逻辑导致CPU占用过高，然后去解决优化对应的bug。