java 多线程高并发读写控制 误区

先看一下下面的错误代码，对写加了synchronized控制，保证了写的安全，但是问题在哪里呢？

public class testTh7 {
	private String data;
	public String read(){
		System.out.println(Thread.currentThread().getName() + "read data " + data);
		return this.data;
	}
	public  synchronized void write(String data){
		System.out.println(Thread.currentThread().getName() + " === write data " + data);
		this.data = data;
	}

	public static void main(String[] args) {
		final testTh7 t = new testTh7();
		for (int i = 0; i < 100; i++) {
			if (i % 2 == 0) {
				new Thread(new Runnable() {
					@Override
					public void run() {
						Double d = Math.random();
						t.write(d.toString());
					}
				}).start();
			} else {
				new Thread(new Runnable() {
					@Override
					public void run() {
						t.read();
					}
				}).start();
			}
		}
	}
}

 程序的前部分输出结果如下：

Thread-1read data null

Thread-0 === write data 0.8429852467390618

Thread-2 === write data 0.3111022600208211

Thread-3read data 0.3111022600208211

Thread-4 === write data 0.13391602356879362

Thread-5read data 0.13391602356879362

Thread-8 === write data 0.3014059888796128

Thread-6 === write data 0.7073336550466512

Thread-7read data 0.7073336550466512

Thread-9read data 0.7073336550466512

Thread-10 === write data 0.3157260014049781

Thread-11read data 0.3157260014049781

Thread-15read data 0.3157260014049781

Thread-14 === write data 0.9981422731405993

Thread-16 === write data 0.9011910270245219

Thread-12 === write data 0.34975057489898076

Thread-13read data 0.34975057489898076

Thread-17read data 0.34975057489898076

Thread-18 === write data 0.19089943846264656

Thread-19read data 0.19089943846264656

Thread-21read data 0.19089943846264656

Thread-20 === write data 0.38498810226852065

Thread-22 === write data 0.29234432278529343

Thread-23read data 0.29234432278529343

Thread-27read data 0.29234432278529343

Thread-24 === write data 0.28981062022967496

Thread-29read data 0.28981062022967496

Thread-28 === write data 0.1022791336198855

Thread-26 === write data 0.15466728987586276

Thread-25read data 0.15466728987586276

Thread-31read data 0.15466728987586276

Thread-32 === write data 0.13431233603464776

Thread-33read data 0.13431233603464776

Thread-35read data 0.13431233603464776

Thread-38 === write data 0.33289010029186195

Thread-37read data 0.13431233603464776

Thread-34 === write data 0.5545937895404677

Thread-30 === write data 0.9567137584265717

Thread-36 === write data 0.6461050880921616

 

可以看到Thread-37这行读取的数据已经不正确了，读取的上一次的旧数据，这不是线程安全的缓存设计。首先确认一下原则，只能有一个线程写操作，可以多个线程并发读，但是写时不能读，读时候不能写。

解决办法有多种，可以使用信号量，使用两个信号量，一个是读写的信号量，还有个是写的信号量，如果简单一点，也可以使用java已经封装的读写锁，代码如下，可以自己测试。

import java.util.concurrent.locks.ReentrantReadWriteLock;

public class testReadWrite {

	private String data = null;
	private ReentrantReadWriteLock rw = new ReentrantReadWriteLock();

	public void read() {
		rw.readLock().lock();
		System.out.println(Thread.currentThread().getName() + " read data!");
		System.out.println(Thread.currentThread().getName() + "read data " + data);
		rw.readLock().unlock();
	}

	public void write(String data) {
		rw.writeLock().lock();
		System.out.println(Thread.currentThread().getName() + " ===write data!");
		this.data = data;
		System.out.println(Thread.currentThread().getName() + " ===write data: " + data);
		rw.writeLock().unlock();
	}

}

 

 

评论

14 楼 qifeifei 2015-05-11  

这个代码很明显有读也有写，但是释放锁没有在finally里面写。

13 楼 focus2008 2015-05-11  

qifeifei 写道

11楼的理解是在读前面也加上synchronized吗？对并发读你怎么解决呢？

如果只有并发读，没有写的话。就不需要锁了，只要保证“被正确的发布”就行了。

如果有读也有写，那么你只在写上加锁，不在读上加锁，那么你就犯了基本的错误了。你看下effective java那本书中关于并发的条目吧。

另外显示锁，你的用法也是有问题的，一般像下面这样用：
rw.writeLock().lock();
try{   
    // ... ...
}finally{
    rw.writeLock().unlock();
}
确保锁一定被释放。

12 楼 qifeifei 2015-05-11  

11楼的理解是在读前面也加上synchronized吗？对并发读你怎么解决呢？

11 楼 LieutenantGeneral 2015-05-09  

1、不是这个并发有问题，是你的理解有问题：你想实现读写互斥，你只是在写方法加了一个synchronized，这样会使得你写的时候不会被其他线程抢占资源，会把你想写入的东西写入。要实现读写互斥，你至少需要对读写加都加一个synchronized，最好用该类的class还作为锁。

2、并发代码写之前还是最好搞清思路，至于说的性能问题，synchronized是一直在优化的，而且一般你工作的时候的代码我估计也不会考虑那么多、

10 楼 haochong 2015-05-09  

楼主的多线程还得多学习哈。。

9 楼 focus2008 2015-05-09  

qifeifei 写道

在多线程环境并存在大量竞争的情况下，synchronized的用时迅速上升，而lock却依然保存不变或增加很少。你可以测试1，50，100，1000，15000个线程同时跑的时间，很明显越到后面，synchronized的用时明显增加，而显示lock一直保持着。

建议你实际测试下，再说。这你的这个例子中，读写比例是1:1，读写锁肯定不比synchronized有优势

8 楼 focus2008 2015-05-09  

ReentrantReadWriteLock的实现是很复杂的，它的执行的代码路径是很长的，所以只有在读比写多很多时，才值得使用。

7 楼 focus2008 2015-05-09  

首先普通的显示锁肯定性能上不比synchronized有优势。另外至于读写锁，只有在读比写多很多的情况下，才比普通的synchronized有优势.普通的显示锁绝对不比synchronized有优势。因为synchronized是内置的，相对而言更好优化，更值得优化，也更有可能会进行优化。

6 楼 qifeifei 2015-05-08  

在多线程环境并存在大量竞争的情况下，synchronized的用时迅速上升，而lock却依然保存不变或增加很少。你可以测试1，50，100，1000，15000个线程同时跑的时间，很明显越到后面，synchronized的用时明显增加，而显示lock一直保持着。

5 楼 剑走天涯 2015-05-08  

qifeifei 写道

synchronized如果都加在读和写上面，会大大影响多线程的并发性。

谁说的，你的依据是什么？在jdk6以后synchronized优化了，不会比你有ReentrantReadWriteLock性能损失多少，在以后的jdk中，synchronized会更加优化，而Lock相关的没什么优化空间了

4 楼 qifeifei 2015-05-08  

synchronized如果都加在读和写上面，会大大影响多线程的并发性。

3 楼 focus2008 2015-05-08  

你没有理解java中synchronized的含义，他是同步的意思，包含两层含义：互斥性和可见性。read()方法为了保证读取到write()方法中赋值的最新的data，必须也同时加上synchronized。当然你用读写锁也可以保证read()方法对data的可见性

2 楼 qifeifei 2015-05-08  

volatile关键字不能保证操作原子性的，它能保证变量在不同线程下的可见性。

1 楼 lilin 2015-05-08  

volatile关键字不行吗？