好记性不如烂笔头

通过运行结果得出结论：main 线程在执行 m1 方法的时候获取到锁，在执行 m2、m3 方法时同样获取到了锁，所以 ReentrantLock 是可重入的。通过运行结果，得出结论： 每次 “插入线程” 都是最后执行。PS：如果不是期望结果，可以运行多次。

通过运行结果得出结论：如果 t1 线程在执行 park 方法之前执行了多次 unpark 方法，第一次执行 park 方法不进入阻塞状态，再一次执行 park 方法将进入阻塞状态。通过运行结果得出结论：如果 t1 线程在执行 park 方法之前执行了 unpark 方法，park 方法不能让 t1 线程进入阻塞状态。通过运行结果得出结论：阻塞的线程在执行 unpark 方法后，恢复运行。main 线程睡眠时间大于 t1 线程睡眠时间。main 线程睡眠时间小于 t1 线程睡眠时间。

wait()：让进入 object 监视器的线程到 waitSet 等待notify()：在 object 上正在 waitSet 等待的线程中挑一个唤醒notifyAll()：让 object 上正在 waitSet 等待的线程全部唤醒它们都是线程之间进行协作的手段，都属于 Object 对象的方法。必须获得此对象的锁，才能调用这几个方法即 Guarded Suspension，用在一个线程等待另一个线程的执行结果。

虽然变量 index 的引用对象指向 Integer(2)，局部变量表的作用域只限于 m2 方法的栈帧，当栈帧出栈，在 main 方法的栈帧中 index 仍然指向 Integer(1)，所以在 main 方法中 index 的值为 1。所以当方法结束，栈帧出栈，打印的是 main 方法栈帧对应的 index 的值（1）为什么在 m1、m2 方法内，index 的值为 2，在main 方法中的值为 1？

当执行到 putstatic（序号为 31 的指令）的时候会引用新的对象，此时如果有新线程执行指令 monitorenter 也会加锁成功，这时候就会有两个线程对整型 i 进行操作，就会出现线程安全问题。通过运行结果得出结论： t1 线程拥有锁， t2 线程等待锁，对象都是同一个（0x000000076adfd5e8）默认情况下，如果整型的范围在-128 ~ 127 内，则复用缓存的包装对象，否则创建一个新的包装对象。针对上述的猜想，我们将 k 调整为100，这时候锁住的对象都是缓存的包装类。

重量级锁竞争的时候，还可以使用自旋（循环尝试获取重量级锁）来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。加锁时 Mark Word 的最后三位是 000（0），即轻量锁。

多个线程读共享资源其实也没有问题，在多个线程对共享资源读写操作时发生指令交错，就会出现问题。以上的结果可能是正数、负数、零。因为 Java 中对静态变量的自增、自减并不是原子操作，要彻底理解，必须从字节码来进行分析。两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了。一个程序运行多个线程本身是没有问题的，问题出在多个线程访问。为了避免临界区的竞态条件发生，有多种手段可以达到目的。

Java 中线程状态有6个，分别为:NEW，RUNNABLE，BLOCKED，WAITING，TIMED_WAITING，TERMINATED。t1 是非守护线程， t2 是守护线程，当 t1 执行完 JVM 中不存在非守护线程，即使 t2 未执行完，也会退出 JVM。运行到 t1 的 join 方法时，t1 运行结束，t2 已运行 1s，所以还需要等到 1s 就可以运行完毕。运行结果：通过打印日志的时间戳，我们可以看出来，如果一个线程的打断标记为 true，则 park 失效。

入参为 Runable 的构造方法会将传入的 Runable 赋值给 Thread 的。属性是不是为 null，如果不为 null 则调用 target 方法。的组合形式有返回值，也可以指定等待时间，其它两种方式没有返回值。Thread 的 run 方法判断其。

jdk1.8处理一些常用需求的流式处理