线程死锁
是指两个或两个以上的线程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。
线程死锁发生的条件
1）互斥条件：指线程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个线程占用。如果此时还有其它线程请求资源，则请求者只能等待，直至占有资源的线程用毕释放。
2）请求和保持条件：指线程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它线程占有，此时请求线程阻塞，但又对自己已获得的其它资源保持不放。
3）不可剥夺条件：指线程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。
4）循环等待条件：指在发生死锁时，必然存在一个线程——资源的环形链，即线程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。
危害
1、线程不工作了，但是整个程序还是活着的2、没有任何的异常信息可以供我们检查。3、一旦程序发生了发生了死锁，是没有任何的办法恢复的，只能重启程序，对正式已发布程序来说，这是个很严重的问题。
解决
关键是保证拿锁的顺序一致
两种解决方式
1、内部通过顺序比较，确定拿锁的顺序；
2、采用尝试拿锁的机制。
public class TryLock {
private static Lock No13 = new ReentrantLock();//第一个锁
private static Lock No14 = new ReentrantLock();//第二个锁
//先尝试拿No13 锁，再尝试拿No14锁，No14锁没拿到，连同No13 锁一起释放掉
private static void fisrtToSecond() throws InterruptedException {
String threadName = Thread.currentThread().getName();
Random r = new Random();
while(true){
if(No13.tryLock()){
System.out.println(threadName
+" get 13");
try{
if(No14.tryLock()){
try{
System.out.println(threadName
+" get 14");
System.out.println("fisrtToSecond do work------------");
break;
}finally{
No14.unlock();
}
}
}finally {
No13.unlock();
}
}
//Thread.sleep(r.nextInt(3));
}
}
//先尝试拿No14锁，再尝试拿No13锁，No13锁没拿到，连同No14锁一起释放掉
private static void SecondToFisrt() throws InterruptedException {
String threadName = Thread.currentThread().getName();
Random r = new Random();
while(true){
if(No14.tryLock()){
System.out.println(threadName
+" get 14");
try{
if(No13.tryLock()){
try{
System.out.println(threadName
+" get 13");
System.out.println("SecondToFisrt do work------------");
break;
}finally{
No13.unlock();
}
}
}finally {
No14.unlock();
}
}
//Thread.sleep(r.nextInt(3));
}
}
private static class TestThread extends Thread{
private String name;
public TestThread(String name) {
this.name = name;
}
public void run(){
Thread.currentThread().setName(name);
try {
SecondToFisrt();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) {
Thread.currentThread().setName("TestDeadLock");
TestThread testThread = new TestThread("SubTestThread");
testThread.start();
try {
fisrtToSecond();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
避免死锁常见的算法有有序资源分配法、银行家算法。
活锁
两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。
解决办法：每个线程休眠随机数，错开拿锁的时间。
线程饥饿
低优先级的线程，总是拿不到执行时间
ThreadLocal
图片1.png
为什么ThreadLocal能保证每个线程的变量互不干扰呢？如图，其实在每个线程中都有一个成员变量threadLocalMap
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals = null;
ThreadLocalMap这个类内部又维护了一个Entry数组，而Entry则是一个可以保存key value的对象，当我们创建一个ThreadLocal保存一个线程中某个特有变量的值时，他会先拿到当前线程的对象，然后从线程中取出当前线程的成员便量ThreadLocalMap，然后将这个值以这个ThreadLocal变量为key（ThreadLocal是被WeakReference包裹的，所以它可以被垃圾清理掉）,以他本身为value放入ThreadLocalMap中的Entry数组中，从而实现了变量的保存
public void set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if (map != null)
map.set(this, value);
else
createMap(t, value);
}
那么他是如何保证每个线程中的值互不影响的？
当我们需要取出这个线程中值的时候，同样仍然是获取到当前线程中的ThreadLocalMap，然后获取到ThreadLocalMap中以这个ThreadLocal对象为key的value值。所以我们看到这里可以明白了，当我们从某个线程中取出某个值的时候，我们其实是从当前线程维护的ThreadLocalMap中取的，所以每个线程之间当然互不干扰了
为什么容易发生内存泄漏
threadlocal会把被保存的对象存储在当前线程的ThreadLocalMap中，所以它的生命周期将会与线程共存，而我们通常会在项目中使用线程池管理线程，核心线程在线程池中是不会被清理的，所以线程持续的时间将不可预测，甚至与JVM的生命周期一致，导致被存储的对象一直存在，也就是value一直存在，但是key(threadlocal)因为是被弱引用包裹的，所以在gc的时候就会被清理。从而出现一种key为null的value，这个value一直存在，但是无法被访问，所以出现内存泄漏。
threadlocal为什么会线程不安全
不正确的使用方法会导致线程安全问题，threadLocal是以自身为key,以对象的引用为value，将对象存储在thread的ThreadlocalMap中，假如多个线程中使用threadlocal保存了同一个value的引用，那么多个线程操作的就是同一个对象，达不到为每个线程创建独立副本的效果。
CAS
首先，原子操作
假定有两个操作A和B(A和B可能都很复杂)，如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完，要么完全不执行B，那么A和B对彼此来说是原子的。
然后，CAS可以实现原子操作
每一个CAS操作过程都包含三个运算符：一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。
CAS的基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环CAS就是在一个循环里不断的做cas操作，直到成功为止。
图片2.png
最后,CAS存在的问题
1.ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A
2.循环时间长开销大
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
3.只能保证一个共享变量的原子操作
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁。
还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对象之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。
网友评论