本文将用到Java内存模型的happens-before偏序关系（下文将简称为hb）以及ConcurrentHashMap的底层模型相关的知识。happens-before相关内容参见：JLS §17.4.5. Happens-before Order、深入理解Java内存模型以及Happens before；ConcurrentHashMap的详细介绍以及底层原理见深入分析ConcurrentHashMap。本文将从ConcurrentHashMap的get，clear，iterator（entrySet、keySet、values方法）三个方法来分析它们的弱一致问题。
Concurrency-interest邮件列表中有人问了这么一个问题：ArrayBlockingQueue中有个对象字段lock，在ArrayBlockingQueue的很多方法中，使用这个lock时都将其先赋值给一个局部变量，然后再通过局部变量调用lock上的方法，而没有直接使用lock字段，如remainingCapacity方法中先将this.lock赋值给一个局部变量lock，然后再使用这个局部变量：
[code lang=”java”]
public class ArrayBlockingQueue {
private final ReentrantLock lock;
//…other fields and methods
public int remainingCapacity() {
final ReentrantLock lock = this.lock;
lock.lock();
try {
return items.length – count;
} finally {
lock.unlock();
}
}
}
[/code]
而不是像这样直接使用类中的字段：
[code lang=”java”]
public class ArrayBlockingQueue {
private final ReentrantLock lock;
//…other fields and methods
public int remainingCapacity() {
this.lock.lock();
try {
return items.length – count;
} finally {
this.lock.unlock();
}
}
}
[/code]
那么为什么要这么做，有什么理由或说法？
原文链接 作者：Dave 译者：卓二妹 校对：丁一
详细描述看Aleksey Shipilev这封邮件 —— 我们期待@Contended已久。JVM会自动为对象字段进行内存布局。通常JVM会这样做：(a)将对象的域按从大到小的顺序排列，以优化占用的空间；(b）打包引用类型的字段，以便垃圾收集器在追踪的时候能够处理相连的引用类型的字段。@Contended让程序能够更明确地控制并发和伪共享。通过该功能我们能够把那些频繁进行写操作的共享字段，从其它几乎是只读或只有少许写操作的字段中分离开来。原则很简单：对共享内容进行读操作的代价小，对共享内容的写操作代价非常高。我们也可以将那些可能会被同一个线程几乎同时写的字段打包到一起。
原文链接 作者：Jakob Jenkov 译者：余绍亮 校对：丁一
所谓Slipped conditions，就是说， 从一个线程检查某一特定条件到该线程操作此条件期间，这个条件已经被其它线程改变，导致第一个线程在该条件上执行了错误的操作。这里有一个简单的例子：
[code lang=”java”]
public class Lock {
private boolean isLocked = true;
public void lock(){
synchronized(this){
while(isLocked){
try{
this.wait();
} catch(InterruptedException e){
//do nothing, keep waiting
}
}
}
synchronized(this){
isLocked = true;
}
}
public synchronized void unlock(){
isLocked = false;
this.notify();
}
}
[/code]
阅读全文
说到并发安全时，我们常提及可见性的问题，通俗点讲就是线程1看不到线程2写入变量v的值（更专业的解释以及是什么导致可见性问题，又该如何解决，见扩展阅读），但一直偏于理论，实际中有没有因可见性而导致问题的例子呢？回答是肯定的，接下来我们一起来看几个例子。
这个例子很简单，新建的线程里有一个普通变量stop，用来表示是否结束循环里的自增操作。主线程启动这个线程后，将该变量置为true，观察线程是否打印出finish loop那行，如果存在可见性问题，主线程修改stop值为true，线程v看stop的值应该还是false。
[code lang=”java”]
class VisibilityThread extends Thread {
private boolean stop;
public void run() {
int i = 0;
System.out.println("start loop.");
while(!getStop()) {
i++;
}
System.out.println("finish loop,i=" + i);
}
public void stopIt() {
stop = true;
}
public boolean getStop(){
return stop;
}
}
public class VisibilityTest {
public static void main(String[] args) throws Exception {
VisibilityThread v = new VisibilityThread();
v.start();
Thread.sleep(1000);//停顿1秒等待新启线程执行
System.out.println("即将置stop值为true");
v.stopIt();
Thread.sleep(1000);
System.out.println("finish main");
System.out.println("main中通过getStop获取的stop值:" + v.getStop());
}
}
[/code]
原文链接 作者：Jakob Jenkov
译者：余绍亮 校对：丁一
嵌套管程锁死类似于死锁， 下面是一个嵌套管程锁死的场景：
线程1获得A对象的锁。 线程1获得对象B的锁（同时持有对象A的锁）。 线程1决定等待另一个线程的信号再继续。 线程1调用B.wait()，从而释放了B对象上的锁，但仍然持有对象A的锁。 线程2需要同时持有对象A和对象B的锁，才能向线程1发信号。 线程2无法获得对象A上的锁，因为对象A上的锁当前正被线程1持有。 线程2一直被阻塞，等待线程1释放对象A上的锁。 线程1一直阻塞，等待线程2的信号，因此，不会释放对象A上的锁， 而线程2需要对象A上的锁才能给线程1发信号……
原文链接 作者：Jakob Jenkov 译者：微凉 校对：丁一
相比Java中的锁(Locks in Java)里Lock实现，读写锁更复杂一些。假设你的程序中涉及到对一些共享资源的读和写操作，且写操作没有读操作那么频繁。在没有写操作的时候，两个线程同时读一个资源没有任何问题，所以应该允许多个线程能在同时读取共享资源。但是如果有一个线程想去写这些共享资源，就不应该再有其它线程对该资源进行读或写（译者注：也就是说：读-读能共存，读-写不能共存，写-写不能共存）。这就需要一个读/写锁来解决这个问题。
Java5在java.util.concurrent包中已经包含了读写锁。尽管如此，我们还是应该了解其实现背后的原理。
以下是本文的主题
原文链接 作者：Jakob Jenkov 译者：申章 校对：丁一
锁像synchronized同步块一样，是一种线程同步机制，但比Java中的synchronized同步块更复杂。因为锁（以及其它更高级的线程同步机制）是由synchronized同步块的方式实现的，所以我们还不能完全摆脱synchronized关键字（译者注：这说的是Java 5之前的情况）。
自Java 5开始，java.util.concurrent.locks包中包含了一些锁的实现，因此你不用去实现自己的锁了。但是你仍然需要去了解怎样使用这些锁，且了解这些实现背后的理论也是很有用处的。可以参考我对java.util.concurrent.locks.Lock的介绍，以了解更多关于锁的信息。
以下是本文所涵盖的主题：
原文链接 作者：Jakob Jenkov 译者：He Jianjun 校对：丁一
在同一程序中运行多个线程本身不会导致问题，问题在于多个线程访问了相同的资源。如，同一内存区（变量，数组，或对象）、系统（数据库，web services等）或文件。实际上，这些问题只有在一或多个线程向这些资源做了写操作时才有可能发生，只要资源没有发生变化,多个线程读取相同的资源就是安全的。
(7 votes, average: 4.00 out of 5)
Loading...
