java并发编程详细

基础概念

 

线程生命周期

 

 

sleep，join，yield，

 

打印程序中所有的线程

 

 

Thread和Runable的区别  Thread 才是 Java 里对线程的唯一抽象，Runnable 只是对任务（业务逻辑）

的抽象。Thread 可以接受任意一个 Runnable 的实例并执行。

 

暂停、恢复和停止操作对应在线程 Thread 的 API 就是 suspend()、resume()

和 stop()。但是这些 API 是过期的，也就是不建议使用的。不建议使用的原因主

要有：以 suspend()方法为例，在调用后，线程不会释放已经占有的资源（比如

锁），而是占有着资源进入睡眠状态，这样容易引发死锁问题。同样，stop()方

法在终结一个线程时不会保证线程的资源正常释放，通常是没有给予线程完成资

源释放工作的机会，因此会导致程序可能工作在不确定状态下。正因为 suspend()、

resume()和 stop()方法带来的副作用，这些方法才被标注为不建议使用的过期方

法

 

线程通过方法 isInterrupted()来进行判断是否被中断，也可以调用静态方法

Thread.interrupted()来进行判断当前

线程是否被中断，不过 Thread.interrupted()

会同时将中断标识位改写为 false。

 

 

线程中的共享和协作

volatile，最轻量的同步机制

volatile 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某

个变量的值，这新值对其他线程来说是立即可见的。

volatile 不能保证数据在多个线程下同时写时的线程安全

volatile 最适用的场景：一个线程写，多个线程读。

 

 

 

ThreadLocal使用

threadLocal通过给每一个线程的数据存到一个备份中以能够并发访问这个变量

 

get方法中 Thread.currentThread()获取到当前线程，然后获得每个线程唯一的ThreadLocalMap

 

TheadLocalMap中存在一个Entry变量

 

可以看到Entry 以ThreadLocal为K值，V即我们需要保存的value数据

 

这样ThreadLocal就实现了为每一个线程存放一个数据备份

 

 

 

引发的内存泄漏分析

 

 

根据我们前面对 ThreadLocal 的分析，我们可以知道每个 Thread 维护一个

ThreadLocalMap，这个映射表的 key 是 ThreadLocal 实例本身，value 是真正需

要存储的 Object，也就是说 ThreadLocal 本身并不存储值，它只是作为一个 key

来让线程从 ThreadLocalMap 获取 value。仔细观察 ThreadLocalMap，这个 map

是使用 ThreadLocal 的弱引用作为 Key 的，弱引用的对象在 GC 时会被回收。

 

图中的虚线表示弱引用。

这样，当把 threadlocal 变量置为 null 以后，没有任何强引用指向 threadlocal

实例，所以 threadlocal 将会被 gc 回收。这样一来，ThreadLocalMap 中就会出现

key 为 null 的 Entry，就没有办法访问这些 key 为 null 的 Entry 的 value，如果当前

线程再迟迟不结束的话，这些 key 为 null 的 Entry 的 value 就会一直存在一条强

引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而这块 value 永

远不会被访问到了，所以存在着内存泄露。

 

只有当前 thread 结束以后，current thread 就不会存在栈中，强引用断开，

Current Thread、Map value 将全部被 GC 回收。最好的做法是不在需要使用

ThreadLocal 变量后，都调用它的 remove()方法，清除数据，即清除掉Entry中的value

 

 

调用yield() 、sleep()、wait()、notify()等方法对锁有何影响？

线程在执行yield()以后，线程持有的锁是不释放的

线程在执行sleep()方法被调用以后，线程持有的锁是不释放的

线程在调用wait()和notify()方法之前，必须要先持有锁。调用了wait()方法以后，锁就会被释放，当wait方法返回的时候，线程会重新持有锁

调动notify(),notifyAll()方法之前，必须要先持有锁，调用notify(),notifyAll()方法本身不会释放锁的,等到 同步方法或同步块执行完以后，才会释放锁。