一个线程调用两次 start()方法会出现什么情况？
一个线程两次调用 start 会出现什么情况?
一个线程两次调用 start()方法会出现什么情况？谈谈线程的生命周期和状态转移。在第二次调用 start() 方法的时候，线程可能处于终止或者其他（非NEW）状态，但是不论如何，都是不可以再次启动的。
调用两次 start ？
Java的线程是不允许启动两次的，第二次调用必然会抛岀 IllegalThreadStateEXception，这是一种运行时异常，多次调用 start 被认为是编程错误。
线程的生命周期
关于线程生命周期的不同状态，在Java5以后，线程状态被明确定义在其公共内部枚举类型java.ang. Thread. State中，分别是：
- 新建（NEW），表示线程被创建出来还没真正启动的状态，可以认为它是个Java内部状态。
- 就绪（ RUNNABLE），表示该线程已经在wM中执行，当然由于执行需要计算资源，它可能是正在运行，也可能还在等待系统分配给它CP∪片段，在就绪队列里面排队。
- 运行（Running）在其他一些分析中，会额外区分一种状态 RUNNING，但是从 Java aPi的角度，并不能表示出来。
- 阻塞（ BLOCKED），这个状态和我们前面两讲介绍的同步非常相关，阻塞表示线程在等待 Monitor lock。比如，线程试图通过synchronized去获取某个锁，但是其他线程已经独占了，那么当前线程就会处于阻塞状态。
- 等待（ WAITING），表示正在等待其他线程釆取某些操作。一个常见的场景是类似生产者消费者模式，发现任务条件尚未满足，就让当前消费者线程等待（wait），另外的生产者线程去准备任务数据，然后通过类似 notify等动作，通知消费线程可以继续工作了。Thread join（也会令线程进入等待状态。
- 计时等待（ TIMED_WAIT），其进入条件和等待状态类似，但是调用的是存在超时条件的方法，比如wait或join等方法的指定超时版本，如下面示例
public final native void wait（long timeout） throws InterruptedException；
- 终止（ TERMINATED），不管是意外退出还是正常执行结束，线程已经完成使命，终止运行，也有人把这个状态叫作死亡在第二次调用 start()方法的时候，线程可能处于终止或者其他（非NEW）状态，但是不论如何，都是不可以再次启动的。
线程状态转换图
线程是什么？
从操作系统的角度，可以简单认为，线程是系统调度的最小单元，一个进程可以包含多个线程，作为任务的真正运作者，有自己的栈（ Stack）、寄存器（ Register）、本地存储 （ Thread Local）等，但是会和迸程内其他线程共享文件描述符、虚拟地址空间等
线程的分类
在具体实现中，线程还分为内核线程、用户线程，Java的线程实现其实是与虚拟机相关的。对于我们最熟悉的sun/ Oracle jDK，其线程也经历了一个演进过程，基本上在Java1.2之后，JDK已经抛弃了所谓的 Green Thread，也就是用户调度的线程，现在的模型是一对一映射到操作系统内核线程。
- https://en.wikipedia.org/wiki/Green_threads
Thread 源码
Thread 源码中大部分逻辑是直接调用 JNI 本地代码。
private native void start0();
private native void setPriority0 (int newPriority);
private native void interrupt0()
- 优点 这种直接调用 JNI 形式的本地代码能精细的控制线程和相关的并发操作，并且拥有高扩展能力。
- 缺点 实现复杂，提高了并发编程的门槛。
线程的基本操作
新建线程
Runnable task =()->System.out.println("Hello World！");
Thread myThread = new Thread(task);
myThread.start();
myThread.join();
直接扩展 Thread 类，然后实例化，上面的例子中， 实现一个 Runnable，将代码逻辑放在 Runnable 中，然后使用 Thread 并启动 start ，等待 join 结束。Runnable 的好处是，不会有多继承的限制，重用代码实现，可以实现重复逻辑。并且能够更好的结合 Java 并发库中的 Executor 框架使用。比如将上面的start,join 可以改写成下面的代码：
Runnable task =()->System.out.println("Hello World！");
Future future = (Future) Executors.newFixedThreadPool(1).submit(task).get();
使用上面的方式，可以不用操心线程的创建和管理。
哪些因素可能影响线程的状态
线程自身的方法
除了 start 之外，还有多个 join 方法等待线程结束。yield 告诉调度器，主动让出 CPU, 另外， 还有些过时方法 resume, stop, suspend,destroy ,stop。
基类 Object 中提供一些基础的 wait/notify/notifyAll方法。
如果我们持有某个对象的某个 Monitor锁，调用 wait 会让当前线程处于等待状态。直到其他线程 notify 或者 notifyAll。本质上是提供了 Monitor 的释放和获取能力。
并发类库中的工具
比如 CountDownLatch.await() 会让线程进入等待状态，知道 latch 基数为0 ，就可以看做是线程间的通讯 Signal.
image
Thread 和 Object 方法 进行线程之间的调度和维护，比较晦涩难懂，一般使用 Java 并发包进行线程的使用。
守护线程
守护线程（Daemon Thread），需要一个长期驻留服务的程序，但是不希望其影响应用退出，就可以设置成守护线程。
Thread daemonThread = new Thread();
daemonThread.setDaemon(true)
daemonThread.start()
再来看看 Spurious wakeuρ。尤其是在多核CP∪的系统中，线程等待存在一种可能，就是在没有仼何线程广播或者发岀信号的情况下，线程就被唤醒，如果处理不当就可能岀现诡异的并发问题，所以我们在等待条件过程中，建议采用下面模式来书写。
- https://en.wikipedia.org/wiki/Spurious_wakeup
//推荐
while(isConditiono())){
waitForAConfition()
}
//不推荐，可能引入bug
if(isCondition()){
waitForAConfition();
}
ThreadLocal
ThreadLocal 内部条目是弱引用， ThreadLocalMap里面的数据存储结构，从上面的代码来看，ThreadLocalMap中存放的就是Entry，Entry的KEY就是ThreadLocal，VALUE就是值。在ThreadLocal的get,set的时候都会清除线程Map里所有key为null的value。但是如果不调用 get set 的话，value不会被清理，就存在内存泄露.
static class ThreadLocalMap {
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
set 方法
private void set(ThreadLocal<?> key, Object value) {
Entry[] tab = table;
int len = tab.length;
int i = key.threadLocalHashCode & (len-1);
for (Entry e = tab[i];
e != null;
e = tab[i = nextIndex(i, len)]) {
ThreadLocal<?> k = e.get();
if (k == key) {
e.value = value;
return;
}
if (k == null) {
// 替换废弃条目
replaceStaleEntry(key, value, i);
return;
}
}
tab[i] = new Entry(key, value);
int sz = ++size;
// 扫码并清理发现的废弃条目，并检查容量是否超限
if (!cleanSomeSlots(i, sz) && sz >= threshold)
rehash();// 清理废弃条目，如果超限，则扩容
}