美文网首页
第三章——对象的共享

第三章——对象的共享

作者: 你可记得叫安可 | 来源:发表于2020-10-17 10:59 被阅读0次

    3.1 可见性

    3.1.3 加锁与可见性

    内置锁可以用于确保某个线程以一种可预测的方法来查看另一个线程的执行结果。当线程 A 执行某个同步代码块时,线程 B 随后进入由同一个锁保护的同步代码块,在这种情况下可以保证,在锁被释放之前,A 看到的变量值在 B 获得锁后同样可以由 B 看到。

    加锁的含义不仅仅局限于互斥行为,还包括内存可见性。为了确保所有线程都能看到共享变量的最新值,所有执行读操作或写操作的线程都必须在同一个锁上同步。

    3.1.4 volatile 变量

    Java 语言提供了一种稍弱的同步机制,即 volatile 变量,用来确保将变量的更新操作通知到其他线程。在访问 volatile 变量时不会执行加锁操作,因此也就不会使执行线程阻塞,因此 volatile 变量是一种比 synchronized 关键字更轻量级的同步机制。
    volatile 变量对可见性的影响比 volatile 变量本身更为重要。当线程 A 首先写入一个 volatile 变量并且线程 B 随后读取该变量时,在写入 volatile 变量之前对 A 可见的所有变量的值,在 B 读取了 volatile 变量之后,对 B 也是可见的。因此,从内存可见性的角度来看,写入 volatile 变量相当于退出同步代码块,而读取 volatile 变量就相当于进入同步代码块。

    volatile 变量的正确使用方式包括:确保它们自身状态的可见性,确保它们所引用对象的状态的可见性,以及标识一些重要的程序生命周期事件的发生(例如,初始化或关闭)。加锁机制既可以确保可见性又可以确保原子性,而 volatile 变量只能确保可见性。

    3.2 安全的对象构造过程

    这一节主要讲的是 this 逃逸的问题。可参看:Java 中的 this 逃逸

    3.3 线程封闭

    3.3.2 栈封闭

    栈封闭是线程封闭的一种特例,在栈封闭中,只能通过局部变量才能访问对象。局部变量的固有属性之一就是封闭在执行线程中。

    public int loadTheArk(Collection<Animal> candidates) {
        SortedSet<Animal> animals;
        int numPairs = 0;
        Animal candidate = null;
        
        // animals 被封闭在方法中,不要使它们逸出!
        animals = new TreeSet<Animal>(new SpeciesGenderComparator());
        animals.addAll(candidates);
        for (Animal a : animals) {
            if (candidate == null || !candidate.isPotentialMate(a)) {
                candidate = a;
            } else {
                ark.load(new AnimalPair(candidate, a));
                ++numPairs;
                candidate = null;
            }
        }
        return numPairs;
    }
    

    注意到 animals 引用被封闭到了局部变量中,因此也被封闭在执行线程中。返回的 numPairs 是一个基本类型,由于任何方法都无法获得对基本类型的引用,因此 Java 语言的这种语义就确保了基本类型的局部变量始终封闭在线程内。

    3.3.3 ThreadLocal 类

    ThreadLocal 原理

    3.4 不变性

    满足同步需求的另一种方法时使用不可变对象(Immutable Object)。

    不可变对象一定是线程安全的
    当满足以下条件时,对象才是不可变的:

    • 对象创建以后其状态就不能修改
    • 对象的所有域都是 final 类型
    • 对象是正确创建的(在对象的创建期间,this 引用没有逸出)
    3.4.2 示例:使用 volatile 类型来发布不可变对象

    在第二章 2.3 的 UnsafeCachingFactorizer 类中,我们尝试用两个 AtomicReferences 变量来保存最新的数值及其因数分解结果,但这种方式并非是线程安全的,因为我们无法以原子方式来同时读取或更新这两个相关的值。然而,在某些情况下,不可变对象能提供一种弱形式的原子性。
    因式分解 Servlet 将执行两个原子操作:更新缓存的结果,以及通过判断缓存中的数值是否等于请求的数值来决定是否直接读取缓存中的因数分解结果。每当需要对一组相关数据以原子方式执行某个操作时,就可以考虑创建一个不可变的类来包含这些数据。

    @Immutable
    class OneValueCache {
        private final BigInteger lastNumber;
        private final BigInteger[] lastFactors;
        
        public OneValueCache(BigInteger i,
                             BigInteger[] factors) {
            lastNumber = i;
            lastFactors = Arrays.copyOf(factors, factors.length);
        }
        
        public BigInteger[] getFactors(BigInteger i) {
            if (lastNumber == null || !lastNumber.equals(i)) {
                return null;
            } else {
                return Arrays.copyOf(lastFactors, lastFactors.length);
            }
        }
    }
    

    上面的 OneValueCache 是不可变类,因为除了构造函数以外,再没有方法能够 写(write) 两个成员变量 lastNumberlastFactors 了。

    构造一个对象涉及到两个主要的过程:

    1. 初始化成员变量的值
    2. 返回对象的地址
      事实上,上面的 OneValueCache 之所以是不可变的,还有一个原因是,它的所有域都是 final 的。如果不是 final 的,那么 Java 编译器可能会优化构造过程:先执行 2 再执行 1。这样就可能会导致:当线程 A 构造 OneValueCache 时,由于先执行 2,因此另一个线程 B 看到 OneValueCache 的引用时,它的成员变量却还没有被初始化,线程 B 访问成员变量时就会值为 0。
    • 但是上面这种优化可能只出现在服务器端采用一些编译选项导致编译器采取了极端的优化策略。在安卓客户端上,应该没有采用这种极端的优化策略,不过我们在编写代码时,依然需要养成良好的代码习惯。

    我们使用 OneValueCache 来改造下 UnsafeCachingFactorizer

    @ThreadSafe
    public class VolatileCachedFactorizer implements Servlet {
        private volatile OneValueCache cache = new OneValueCache(null, null);
        
        public void service(ServletRequest req, ServletResponse resp) {
            BigInteger i = extractFromRequest(req);
            BigInteger[] factors = cache.getFactors(i);
            if (factors == null) {
                factors = factor(i);
                cache = new OneValueCache(i, factors);
            }
            encodeIntoResponse(resp, factors);
        }
    }
    

    cache 相关的操作不会相互干扰,因为 OneValueCache 是不可变的,并且在每条相应的代码路径中只会访问它一次。通过使用包含多个状态变量的容器对象来维持不变性条件,并使用一个 volatile 类型的引用来确保可见性,使得 VolatileCachedFactorizer 在没有显式地使用锁的情况下仍然是线程安全的。

    3.5 安全发布

    3.5.2 不可变对象与初始化安全性

    由于不可变对象(应该对应于 Kotlindata class)是一种非常重要的对象,因此 Java 内存模型为不可变对象的共享提供了一种特殊的初始化安全性保证。为了维持这种初始化安全性的保证,必须满足不可变性的所有需求:状态不可修改,所有域都是 final 类型,以及正确的构造过程。

    3.5.3 安全发布的常用模式

    要安全地发布一个对象,对象的引用以及对象的状态必须同时对其他线程可见。一个正确构造的对象可以通过以下方式来安全地发布:

    • 在静态初始化函数中初始化一个对象引用。(由于在在 JVM 内部存在着同步机制,因此通过这种方法初始化的任何对象都可以被安全地发布)
    • 将对象的引用保存到 volatile 类型的域或者 AtomicaReference 对象中。
    • 将对象的引用保存到某个正确构造对象的 final 类型域中。
    • 将对象的引用保存到一个由锁保护的域中。

    在线程安全容器内部的同步意味着,在将对象放入到某个容器,例如 VectorsynchronizedList 时,将满足上述最后一条需求。如果线程 A 将对象 X 放入一个线程安全的容器,随后线程 B 读取这个对象,那么可以确保 B 看到 A 设置的 X 状态,即便在这段读 / 写 X 的应用程序代码中没有包含显示的同步。

    3.5.4 事实不可变对象

    如果对象从技术上来看是可变的,但其状态在发布后不会再改变,那么把这种对象称为“事实不可变对象(Effectively Immutable Object)”。这些对象不需要满足 3.4 节中提出的不可变性的严格定义。在这些对象发布后,程序只需将它们视为不可变对象即可。通过使用事实不可变对象,不仅可以简化开发过程,而且还能由于减少了同步而提高性能。

    3.5.5 可变对象

    如果对象在构造后可以修改,那么安全发布只能确保“发布当时”状态的可见性。要安全地共享可变对象,这些对象就必须被安全地发布,并且必须是线程安全的或者由某个锁保护起来的。

    相关文章

      网友评论

          本文标题:第三章——对象的共享

          本文链接:https://www.haomeiwen.com/subject/rvdjpktx.html