浅谈 Java 多线程

        首先，我们来整体看一下线程是什么？从操作系统的角度，可以简单认为，线程是系统调度的最小单元，一个进程可以包含多个线程，作为任务的真正运作者，有自己的栈，寄存器，本地存储等。但是会和进程内其他线程共享文件描述符，虚拟地址空间等。在具体实现中，线程还分为内核线程，用户线程，Java 的线程实现其实是与虚拟机相关的。

第一，一个线程可以两次调用 start（）方法吗？

        Java 的线程是不允许启动，第二次调用必然会抛出 IllegalThreadStateException，这是一种运行时异常，多次调用 start 被认为是编程错误。

        关于线程生命周期的不同状态，在 Java 5 以后，线程状态被明确定义在其公共内部枚举类型 java.lang.Thread.State 中，分别是：

        新建（NEW），表示线程被创建出来还没真正启动的状态，可以认为它是个 Java 内部状态。

        就绪（RUNNABLE）,表示该线程已经在 JVM 中执行，当然由于执行需要计算资源，它可能是正在运行，也可能还在等待系统分配给它 CPU 片段，在就绪队列里面排队。在其它一些分析中，会额外区分一种状态 RUNNING，但是从 JAVA API 的角度，并不能表示出来。

        阻塞（BLOCKED），这个状态和我们前面两讲介绍的同步非常相关，阻塞表示线程在等待 Monitor lock。比如，线程试图通过 synchronized 去获取某个锁，但是其它线程已经独占了，那么当前线程就会处于阻塞状态，或者线程调用 sleep() 方法进入阻塞状态。yield()  方法是一个和 sleep() 方法有点相似的方法，它也是 Thread 类提供的一个静态方法。可以让当前正在执行的线程暂停，但它不会阻塞该线程，只是将该线程转入就绪状态。yeild() 只是让当前线程暂停一下，让系统的线程调度器重新调度一次，完全可能的情况是：当某个线程调用了 yield() 线程暂停之后，线程调度器又将其调度出来重新执行。

        等待（WAITING），表示正在等待其它线程采取某些操作。一个常见的场景是类似生产者消费者模式，发现任务条件尚未满足，就让当前消费者等待（wait），另外的生产者线程去准备任务数据，然后通过类似 notify 等动作，通知消费线程可以继续工作了。Thread.join（）也会令线程进入等待状态。解释一下 Thread.join（），是主线程等待子线程的终止。也就是说主线程的代码块中，如果碰到了 t.join（） （t 是子线程）方法，此时主线程需要等待（阻塞），等待子线程结束了 (Waits for this thread to die.) ，才能继续执行 t.join（） 之后的代码块。join（）和 wait（）不会释放锁，join（）是 Thread 的方法，wait（）是 Object 的方法。

        计时等待（TIMED_WAIT），其进入条件和等待状态类似，但是调用的是存在超时条件的方法，比如 wait 和 join 等方法的指定超时版本。

        终止（TERMINATED），不管是意外退出还是正常执行结束，线程已经完成使命，终止运行，也有人把这个状态叫做死亡。

        第二次调用 start（）方法的时候，线程可能处于终止或者其他（非 NEW）状态，但是不论如何，都不是可以启动的。

第二，什么情况下 Java 程序会产生死锁？如何定位，修复？

        死锁是一种特定的程序状态，在实体之间，由于循环依赖导致彼此一直处于等待之中，没有任何个体可以继续前进。死锁不仅仅是在线程之间会发生，存在资源独占的进程之间同样也可能出现死锁。通常来说，我们大多是聚焦在多线程场景种的死锁，指两个或多个线程之间，由于互相持有对方需要的锁，而永久处于阻塞的状态。如下图：

        定位死锁最常见的方式就是利用 jstack 等工具获取线程栈，然后定位互相之间的依赖关系，进而找到死锁。如果是比较明显的死锁，往往 jstack 等就能直接定位，类似 JConsole 甚至可以在图形界面进行有限的死锁检测。如果程序运行时发生了死锁，绝大多数情况下都是无法在线解决的，只能重启，修正程序本身问题。所以，代码开发阶段互相审查，或者利用工具进行预防性排查，往往也是很重要的。

第三，如何在编程中尽量预防死锁？

        首先，我们来总结一下前面例子中死锁的产生包含哪些基本元素。基本上死锁的发生时因为：1，互斥条件，类似 Java 中 Monitor 都是独占的，要么是我用，要么是你用。2，互斥条件是长期持有的，在使用结束之前，自己不会释放，也不能被其他线程抢占。3，循环依赖关系，两个或者多个个体之间出现了锁的链条环。所以，我们可以据此分析可能的避免死锁的思路和方法。

        第一种方法：尽量避免使用多个锁，并且只有需要时才持有锁。否则，即使是非常精通并发编程的工程师，也难避免会掉进坑里，嵌套的 synchronized 或者 lock 非常容易出问题。所以，从程序设计的角度反思，如果我们赋予一段程序太多的职责，出现 “既要。。又要。。” 的情况时，可能就需要我们审视下设计思路或目的是否合理了。对于类库，因为其基础，共享的定位，比应用开发往往更加令人苦恼，需要仔细斟酌之间的平衡。

        第二种方法：如果必须使用多个锁，经量设计好锁的获取顺序，这个说起来简单，做起来可不容易，可以参看著名的银行家算法。

        第三种方法：使用带超时的方法，为程序带来更多可控性。类似 Object.wait(...) 或者 CountDownLatch.await(...)，都支持所谓的 timed_wait，我们完全可以就不假定该锁一定会获得，指定超时时间，并为无法得到锁时准备退出逻辑。并发 Lock 实现，如 ReentrantLock 还支持非阻塞式的获取锁操作 tryLock()，这是一个插队行为，并不在乎等待的公平性，如果执行时对象恰好没有被独占，则直接获取锁。

        第四种方法：通过静态代码分析去查找固定的模式，进而定位可能的死锁或者竞争情况。 死锁的另一个好朋友就是饥饿。死锁和饥饿都是线程活跃性问题。实践中死锁可以使用 jvm 自带的工具进行排查。死循环死锁可以认为是自旋锁死锁的一种，其他线程因为等待不到具体的信号提示。导致线程一直饥饿。这种情况下可以查看线程 cpu 使用情况，排查出使用 cpu 时间片最高的线程，再打出该线程的堆栈信息，排查代码。基于互斥量的锁如果发生死锁往往 cpu 使用率较低，实践中也可以从这一方面进行排查。