《Java并发编程实战》---第2章(线程安全性)

2.1 什么是线程安全性

/*线程不安全*/
/*原因就是多个线程对共享、可变变量的并发访问,多个线程以不可预算的速度推进*/
@NotThreadSafe
public class UnsafeSequence{
	private int value;

	public int getNext(){
		return value++;
	}
}

/*线程安全*/
@ThreadSafe
public class Sequence{
	@GuardedBy("this") private int value;

	public synchronized int getNext(){
		return value++;
	}
}

《Java并发编程实战》---第2章(线程安全性)_第1张图片

示例:一个无状态的Servlet

《Java并发编程实战》---第2章(线程安全性)_第2张图片

2.2 原子性

《Java并发编程实战》---第2章(线程安全性)_第3张图片
由于这个对象包含了一个成员变量count(就是上文所说的域,这是线程共享的),多线程访问count的时候,都是读取count的值,然后对值加1,最后把结果写入count,这样的“读取-修改-写入”的操作序列导致了多线程并发的线程安全问题。如下例子:
《Java并发编程实战》---第2章(线程安全性)_第4张图片
A,B两个线程同时拿到count的值是9,都进行了加1操作,写回count的都是10,这就导致不能正确统计处理请求的数量了!怎么办?可以把“读取-修改-写入”这三个操作复合成一个操作(原子性),就可以了,下面代码使用了java.util.concurrent.atomic包下的原子变量类AtomicLong。
《Java并发编程实战》---第2章(线程安全性)_第5张图片

2.3 加锁机制

如本书作者所说,能不能继续使用2.2的原子类实现对上一次因数分解结果的缓存呢?如下代码:
《Java并发编程实战》---第2章(线程安全性)_第6张图片
遗憾的是,上面的代码并不能达到预期效果,原因是下面的两行代码各自都是原子的,但这两行代码应该是整体原子的,这一点没保证。导致的结果是线程不安全,比如A线程设置了lastNumber,B线程设置了lastFactors,这就导致了存储的lastNumber和lastFactors不对应,而当C线程使用这个缓存的时候,就出错了。。

lastNumber.set(i);
lastFactors.set(factors);

2.3.1 内置锁

《Java并发编程实战》---第2章(线程安全性)_第7张图片
《Java并发编程实战》---第2章(线程安全性)_第8张图片
《Java并发编程实战》---第2章(线程安全性)_第9张图片

2.3.2 重入

《Java并发编程实战》---第2章(线程安全性)_第10张图片
《Java并发编程实战》---第2章(线程安全性)_第11张图片
在这里插入图片描述

2.4 用锁来保护状态

《Java并发编程实战》---第2章(线程安全性)_第12张图片
《Java并发编程实战》---第2章(线程安全性)_第13张图片
下面代码注意,if后的条件如果为真,判断完后锁就释放了,和执行下面的语句之间有间隙,这个间隙内由于别的线程做某些修改可能导致之前的if条件判断失效,当本线程再次执行下面的语句时就搞坏事了。
《Java并发编程实战》---第2章(线程安全性)_第14张图片

2.5 活跃性与性能

2.3.1中简单粗粒度的对service方法加锁,虽然保证了线程安全,但付出代价很高!
《Java并发编程实战》---第2章(线程安全性)_第15张图片
《Java并发编程实战》---第2章(线程安全性)_第16张图片
《Java并发编程实战》---第2章(线程安全性)_第17张图片
《Java并发编程实战》---第2章(线程安全性)_第18张图片

你可能感兴趣的:(Java并发)