`

多线程

 
阅读更多
Java提供了强制原子性的内置锁机制:synchronized块。

一个synchronized块有两部分:对象的引用,以及这个锁保护的代码块。

每个Java对象都可以隐式地扮演一个用于同步的锁的角色;这些内置的锁被称为内部锁或监听器锁。执行线程进入synchronized块之前会自动获得锁;而无论通过正常控制路径退出,还是从块中抛出异常,线程都在放弃对synchronized块的控制时自动释放锁。获得内部锁的唯一途径是:进入这个内部锁保护的同步块或方法。

内部锁在Java中扮演了互斥锁的角色。

重进入:
当一个线程请求其他线程已经占有的锁时,请求线程将被阻塞。然而内部锁是可重进入的,因为线程在试图获得它自己占有的锁时,请求会成功。

重进入意味着所有的请求是基于“每个线程”,而不是基于“每个调用”的。

重进入方便了锁行为的封装,因此简化了面向对象并发代码。否则子类复写父类的synchronized类型的方法,并调用父类中的方法,那么就会产生死锁了。

你不可以将一个原子操作分解到多个synchronized块中。不过你应该尽量从synchronized块中分离耗时的且不影响共享状态的操作。
public void service(ServletRequest req, ServletResponse resp) {
        BigInteger i = extractFromRequest(req);
        BigInteger[] factors = null;
        synchronized (this) {
            ++hits;
            if (i.equals(lastNumber)) {
                ++cacheHits;
                factors = lastFactors.clone();
            }
        }
        if (factors == null) {
            factors = factor(i);
            synchronized (this)  {
                lastNumber = i;
                lastFactors = factors.clone();
            }
        }
        encodeIntoResponse(resp, factors);
}

    请求与释放锁的操作需要开锁,所以将synchronized块分解得过于琐碎是不合理的,即使这样做是为了获得更好的原子性。当访问状态变量或者执行复合操作期间,CachedFactorizer会占有锁,但是执行潜在耗时的因数分解之前,它会释放锁。这样即保护了线程安全性,也不会过多地影响并发性。
public class NoVisibility {
    private static boolean ready;
    private static int number;
    private static class ReaderThread extends Thread {
        public void run() {
            while (!ready)
                Thread.yield();
            System.out.println(number);
            }
        }
    public static void main(String[] args) {
        new ReaderThread().start();
        number = 42;
        ready = true;
    }
}
    Novisibility可能会一直保持循环,因为对于读线程来说,ready的值可能永远不可见。甚至可能会打印0,因为早在number赋值之前,主线程就已经写入ready并使之对读取线程可见,这是一种重拍序现象。读线程看到的顺序可能与发生写入的顺序正好相反,或者完全不同。
在没有同步的情况下,编译器,处理器,运行时安排操作的执行顺序可能完全出人意料。在没有进行适当同步的多线程程序中,尝试推断那些“必然”发生在内存中的动作时,你总是会判断错误。
有一个简单的方法来避免这些复杂的问题:只要数据需要被跨线程共享,就进行恰当的同步。

编写正确的并发程序的关键在于对共享的、可变的状态进行访问管理。


非原子的64位操作
JVM允许将64位的读或写划分为两个32位的操作。如果读和写发生在不同的线程,这种情况读取一个非volatile类型long就可能会出现得到一个值的高32位和另一个值的低32位。伪共享。

Volatile变量
当一个域声明为volatile类型后,编译器与运行时会监视这个变量,它是共享的,而且对它的操作不会与其他的内存操作一起被重排序。Volatice变量不会缓存在寄存器或者缓存在对其他处理器隐藏的地方。所以,读一个volatile类型的变量时,总会返回由某一线程所写入的最新值。

然而访问volatile变量的操作不会加锁,也就不会引起执行线程的阻塞,这使得volatile变量相对于synchronized而言,只是轻量级的同步机制。

正确使用volatile变量的方式包括:用于确保它们所引用的对象的状态的可见性,或者用于标识重要的生命周期事件的发生。
下面的例子示范了一种volatile变量的典型应用;检查状态标记,以确定是否退出一个循环。Asleep标记就必须是volatile的,否则执行检查的线程不会注意到asleep已被其他线程修改。
volatile boolean asleep;
...
    while (!asleep)
        countSomeSheep();

注意volatile的语义不足以使自增操作原子化,原子变量提供了“读改写”原子操作的支持,而且常被用作更优的volatile变量。
加锁可以保证可见性与原子性,volatile变量只能保证可见性。
只有满足了下面所有的标准后,你才能使用volatile变量:
1. 写入变量时并不以来变量的当前值;或者能够确保只有单一的线程修改变量的值。
2. 变量不需要与其他的状态变量共同参与不变约束。
3. 而且,访问变量时,没有其他的原因需要加锁。

发布和逸出
    一个对象在尚未准备好时就将它发布,这种情况叫做逸出。
class UnsafeStates {
    private String[] states = new String[] {
        "AK", "AL" ...
    };
    public String[] getStates() { return states; }
}
以上面这种方式发布states会出现问题。任何一个调用者都能够修改它的内容。这个例子中states已经逸出它所属的范围。

线程封闭
线程封闭技术是实现线程安全的最简单方式之一。

ThreadLocal
它允许你将每个线程与持有数据的对象关联在一起。通过利用ThreadLocal存储JDBC连接。
这项技术还用于下面的情况:一个频繁执行的操作既需要像buffer这样的临时对象,同时还需要避免每次都重分配该临时对象。
与线程相关的值存储在线程对象自身中,线程终止后,这些值会被垃圾回收。

不可变性:
不可变对象永远是线程安全的。
只有满足如下状态,一个对象才是不可变的。
1. 它的状态不能在创建后再被修改。
2. 所有域都是final类型
3. 它被正确创建(创建期没有发生this引用的逸出)

使用volatile发布不可变对象
不论何时,对一组相关数值都应该执行原子操作,并且可以考虑为它们创建不可变的容器类,比如下面的OneValueCache。通过使用不可变对象来持有所有的变量,可以消除在访问和更新这些变量时的竞争条件。若使用可变的容器对象,你就必须使用锁以确保原子性;使用不可变对象,一旦一个线程获得了它的引用,永远不必担心其他线程会修改它的状态。
@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);
} }


重点:当一个线程设置volatile类型的cache域引用到一个新的OneValueCache后,新数据会立即对其他线程可见。
与cache域相关的操作不会相互干扰,因为OneValueCache是不可变的,而且每次只有一条相应的代码路径访问它。不可变的容器对象持有与不变约束相关的多个状态变量,并利用volatile引用确保及时的可见性。
目前为止我们都关注确保对象不会被发布。比如,让对象限制在线程中或者另一个对象的内部。
@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);
    }
}

安全发布的模式
如果一个对象不是不可变的,它就必须被安全地发布,通常发布线程与消费线程都必须同步化。
为了安全地发布对象,对象的引用以及对象的状态必须同时对其他线程可见。一个正确创建的对象可以通过下列条件安全地发布。
1. 通过静态初始化器初始化对象的引用;
2. 将它的引用存储到volatile域或AtomicReference;
3. 将它的引用存储到正确创建的对象的final域中。
4. 或者将它的引用存储到由锁正确保护的域中。
4条中的:置入Hashtable、synchronizedMap、ConcurrentMap中的主键以及键值,会安全地发布到可以从Map获得它们的任意线程中,无论是直接获得还是通过迭代器或者。
通常,以最简单和最安全的方式发布一个被静态创建的对象,就是使用静态初始化器:
public static Holder holder = new Holder(42)
静态初始化由JVM在类的初始阶段执行,由JVM内在的同步,该机制确保了以这种方式初始化的对象可以被安全地发布。

安全地共享对象
在并发程序中,使用和共享对象的一些最有效的策略如下:
1. 线程限制:一个线程限制的对象,通过限制在线程中,而被线程独占,且只能被占有它的线程修改。
2. 共享只读:一个共享只读对象,在没有额外同步的情况下,可以被多个线程并发地访问,但是任何线程都不能修改它。共享只读对象包括可变对象与搞笑不可变对象。
3. 共享线程安全:一个线程安全的对象在内部进行同步,所以其他线程无须额外同步,久可以通过公共接口随意地访问它。
4. 被守护的:一个被守护的对象只能通过特定的锁来访问。被守护的对象包括那些被线程安全对象封装的对象,和已知被特定的锁保护起来的已发布对象。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics