线程与进程知识入门（二）

最新推荐文章于 2022-07-03 19:30:25 发布

哎呀小嘿

最新推荐文章于 2022-07-03 19:30:25 发布

阅读量270

点赞数 1

分类专栏： Java 文章标签： java 多线程

本文链接：https://blog.csdn.net/darling_R/article/details/118726918

版权

Java 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文深入探讨了Java中的锁机制，包括死锁的产生条件及其解决方案，活锁的概念与避免方法，锁的四种状态，特别是偏向锁和自旋锁的工作原理。此外，还介绍了乐观锁与悲观锁的对比，以及CAS无锁算法的基本原理和潜在问题。同时，讲解了ThreadLocal如何确保线程安全以及内存泄露问题，为理解Java多线程编程提供了全面的知识。

摘要由CSDN通过智能技术生成

线程与进程知识入门（一）
线程与进程知识入门（三）

锁的分类

死锁

指两个或两个以上的线程在执行过程中，由于各自都已经持有了自己的资源，在此基础上需要其他线程已经持有的资源，其他线程也是同样，就造成了互不相让的情况，导致了线程的阻塞，在没有外力的情况下都难以继续执行下去，即为线程死锁。
产生死锁的条件：

互斥条件：即一个资源在某一时间段内只能被一个线程持有，如果有其他线程想持有，只能等待其释放之后才可以
请求和保持：即一个线程已经持有一个资源，此时还需要另一个新的资源，但是新资源已经被其他线程所持有，自己无法获取，然而对自己已经持有的资源也不释放；
不剥夺：即一个线程持有一个资源以后，在其使用完之前，不能被其他线程强制剥夺，只有自己使用完了才能释放；
环路等待：多个线程之间希望获取的新的资源之间形成一种头尾相接的现象，比如线程{P0,P1,P2…Pn},P0需要P1的资源，P1需要P2的资源…Pn需要P0的资源

打破以上4个必要条件之一就可以有效的避免死锁问题的发生

打破互斥条件：这个条件我们没有办法破坏，因为我们用锁本来就是想让他们互斥的（临界资源需要互斥访问）
打破请求和保持：提前申请所有资源，都申请到的时候才去执行，否则就继续等待，避免出现先持有一个之后有继续申请下一个
打破不剥夺：在一个线程获取一个资源之后，在获取下一个资源的时候，如果获取不到，就让其释放已经获取的资源；（别人无法剥夺的时候，自己要主动释放）
打破环路等待：对资源进行有序编号，所有线程都必须按照顺序去申请资源，即所有线程申请的第一个资源都是1号资源，申请到1号之后才能继续申请2号资源，这样就不会出现环路等待的问题了

活锁

两个线程在尝试拿锁（tryLock）的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。
解决办法：每个线程休眠随机数，错开拿锁的时间。

锁的状态

一共有四种状态，无锁状态，偏向锁状态，轻量级锁状态和重量级锁状态，它会随着竞争情况逐渐升级。锁可以升级但不能降级，目的是为了提高获得锁和释放锁的效率，减少不必要的CAS操作。

偏向锁

大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
偏向锁，顾名思义，它会偏向于第一个访问锁的线程，如果在运行过程中，没有其他线程过来争抢锁，线程是不需要触发同步的，减少加锁/解锁的操作（例如等待队列的CAS操作），这种情况下，就会给线程添加一个偏向锁。如果在执行过程中遇到了其他线程过来抢占锁，持有偏向锁的线程就会被挂起，JVM会消除它本身的偏向锁，升级为轻量级锁。通过消除资源无竞争情况下的同步，提高程序的性能。

自旋锁

原理

如果持有锁的线程可以在很多的时间内完成操作并释放锁，那么即将获取锁的线程就没必要进行状态切换进入阻塞状态，只需要稍微等一下（自旋），等待锁释放之后就可以直接获取锁，这样就避免了一定的性能消耗。
自旋，即可以理解为死循环，也是需要消耗CPU的，而且是在做无用功，所以线程不能一直占用着CPU做无用功，需要给它设置一个自旋等待时间，超时之后就会切换状态停止自旋，进入阻塞状态。

优点

由于自旋的消耗远小于线程被挂起进入阻塞过程的消耗，所以对于那种占用锁的时间特别短的代码块来说，性能会大幅度提升

缺点

如果占用锁的代码块耗时较长，这时候自旋就会长时间占用CPU做无用功，会出现“站着茅坑不拉屎”的现象，自旋本身就已经超出线程挂起的资源小号，这样就导致了CPU的资源浪费。

自旋阈值

JVM对于自旋次数的选择，jdk1.5默认为10次，在1.6引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定，基本认为一个线程上下文切换的时间是最佳的一个时间

锁的比较

在这里插入图片描述

悲观锁&乐观锁

悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中 synchronized 和 ReentrantLock 等独占锁就是悲观锁思想的实现。
乐观锁
总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

CAS基本原理

compare and swap（比较且互换），是一种有名的无锁算法。无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。

原子操作

所谓原子，就是不可再分，即假定有两个操作A和B(A和B可能都很复杂)，一个线程执行A，对于别的线程来说，要么等待A执行完，要么干脆不执行A，可以理解为0和1，只有0和100%的2种情况；
实现原子操作可以使用锁；锁机制满足基本的需求是没有问题的了，但是有的时候我们的需求并非这么简单，我们需要更有效，更加灵活的机制，synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁，
这里会有些问题：首先，如果被阻塞的线程优先级很高很重要怎么办？其次，如果获得锁的线程一直不释放锁怎么办？（这种情况是非常糟糕的）。还有一种情况，如果有大量的线程来竞争资源，那CPU将会花费大量的时间和资源来处理这些竞争，同时，还有可能出现一些例如死锁之类的情况，最后，其实锁机制是一种比较粗糙，粒度比较大的机制，相对于像计数器这样的需求有点儿过于笨重。
实现原子操作还可以使用当前的处理器基本都支持CAS()的指令，只不过每个厂家所实现的算法并不一样，每一个CAS操作过程都包含三个运算符：一个内存地址V，一个期望的值A和一个新值B，操作的时候如果这个地址上存放的值等于这个期望的值A，则将地址上的值赋为新值B，否则不做任何操作。
CAS的基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环CAS就是在一个循环里不断的做cas操作，直到成功为止
在这里插入图片描述

CAS中的问题

ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了
ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A
循环时间长开销大
自旋CAS（也就是不成功就一直循环执行直到成功）如果长时间不成功，会给CPU带来非常大的执行开销
只能保证一个共享变量的原子操作
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效，这个时候可以用锁；
但是从 JDK 1.5开始，提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用AtomicReference类把多个共享变量合并成一个共享变量来操作

ThreadLocal辨析

实现每一个线程都有自己的专属本地变量，可以将ThreadLocal类形象的比喻成存放数据的盒子，盒子中可以存储每个线程的私有数据。

如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的本地副本，这也是ThreadLocal变量名的由来。他们可以使用 get（）和 set（）方法来获取默认值或将其值更改为当前线程所存的副本的值，从而避免了线程安全问题。

void set(Object value)：设置当前线程的线程局部变量的值
public Object get()：该方法返回当前线程所对应的线程局部变量
public void remove()：将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但它可以加快内存回收的速度。
protected Object initialValue()：返回该线程局部变量的初始值，该方法是一个protected的方法，显然是为了让子类覆盖而设计的。这个方法是一个延迟调用方法，在线程第1次调用get()或set(Object)时才执行，并且仅执行1次。

public final static ThreadLocal<String> RESOURCE = new ThreadLocal<String>();

RESOURCE代表一个能够存放String类型的ThreadLocal对象。此时不论什么一个线程能够并发访问这个变量，对它进行写入、读取操作，都是线程安全的。

实现解析

在这里插入图片描述

上面先取到当前线程，然后调用getMap方法获取对应的ThreadLocalMap，ThreadLocalMap是ThreadLocal的静态内部类，然后Thread类中有一个这样类型成员，所以getMap是直接返回Thread的成员。

可以看到有个Entry内部静态类，它继承了WeakReference，总之它记录了两个信息，一个是ThreadLocal<?>类型，一个是Object类型的值。getEntry方法则是获取某个ThreadLocal对应的值，set方法就是更新或赋值相应的ThreadLocal对应的值。

回顾我们的get方法，其实就是拿到每个线程独有的ThreadLocalMap，然后再用ThreadLocal的当前实例，拿到Map中的相应的Entry，然后就可以拿到相应的值返回出去。当然，如果Map为空，还会先进行map的创建，初始化等工作

内存泄露问题

ThreadLocalMap 中使用的 key 为 ThreadLocal 的弱引用,而 value 是强引用。所以，如果 ThreadLocal 没有被外部强引用的情况下，在垃圾回收的时候，key 会被清理掉，而 value 不会被清理掉。这样一来，ThreadLocalMap 中就会出现 key 为 null 的 Entry。假如我们不做任何措施的话，value 永远无法被 GC 回收，这个时候就可能会产生内存泄露。ThreadLocalMap 实现中已经考虑了这种情况，在调用 set()、get()、remove() 方法的时候，会清理掉 key 为 null 的记录。使用完 ThreadLocal方法后最好手动调用remove()方法

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);//k成了弱引用
        value = v;
    }
}

如果一个对象只具有弱引用，那就类似于可有可无的生活用品。弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java 虚拟机就会把这个弱引用加入到与之关联的引用队列中。