《Java并发编程实战》对线程安全作出了一个比较恰当的定义:当多个线程同时访问一个对象时,如果不需要考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那就称这个对象是线程安全的。
讨论线程安全,将以多个线程之间存在共享数据访问为前提。否则线程是串行执行还是多线程执行根本没有任何区别。
但线程安全并不是分为安全和不安全两类,而是以【安全程度】来分为5类:
在Java语言里,不可变的对象一定是线程安全的,无论是对象的方法实现或是方法的调用者,都不需要进行任何的线程安全保障措施。
如果多线程共享的数据是一个基本数据类型,使用final关键字修饰它就可以保证是不可变的;对于引用数据类型,就需要对象自行保证其行为不会对其状态产生影响。
例如java.lang.String类,它是一个典型的不可变对象,用户调用其substring()、replace()、concat()这些方法都不回影响它原来的值,只会返回一个新构造的字符串对象。
保证对象状态不变的方法有很多种,最简单的就是把对象里带有状态定义的变量都声明为final,例如java.lang.Integer类,它将value定义为final来保障不变。
“不管运行时环境如何,调用者都不需要任何额外的同步措施”
Java语言中标注自己是线程安全的类,使用起来都不是绝对线程安全。例如Vector,它是一个线程安全的容器,类里面的方法都使用了synchronized修饰,但并不意味着调用它的方法就是绝对线程安全的,例如:
- public static void main(String[] args) {
- while(true){
- for(int i = 0; i < 10; i++){
- vector.add(i);
- }
- Thread removeThread = new Thread(new Runnable() {
- @Override
- public void run() {
- for(int i = 0; i < vector.size(); i++){
- vector.remove(i);
- }
- }
- });
-
- Thread printThread = new Thread(new Runnable() {
- @Override
- public void run() {
- for(int i = 0; i < vector.size(); i++){
- System.out.println(vector.get(i));
- }
- }
- });
-
- removeThread.start();
- printThread.start();
- //不要产生太多的线程
- while(Thread.activeCount() > 20);
- }
- }
运行这段代码可能就会抛出异常ArrayIndexOutOfBoundsException,虽然Vector的方法都是线程同步的,但如果在调用的时候不加同步措施,那么这段代码仍然是线程不安全的。因为如果一个线程刚好删除了一个元素,而另一个线程又需要get()这个元素,就会抛出异常。所以,我们需要加上额外的同步措施:
- Thread removeThread = new Thread(new Runnable() {
- @Override
- public void run() {
- synchronized (vector){
- for(int i = 0; i < vector.size(); i++){
- vector.remove(i);
- }
- }
- }
- });
-
- Thread printThread = new Thread(new Runnable() {
- @Override
- public void run() {
- synchronized (vector){
- for(int i = 0; i < vector.size(); i++){
- System.out.println(vector.get(i));
- }
- }
- }
- });
就是我们通常意义上讲的线程安全,需要保证对这个对象单词的操作是线程安全的。我们在单次操作调用方法时不需要使用额外的同步措施,但对于一些顺序性的连续调用,就需要额外保障了。
在Java中,大部分声称线程安全的类都属于相对线程安全。例如Vector、HashTable、Collections的synchronizedCollection()方法包装的集合等。
线程兼容是指对象本身不是线程安全的,但可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全使用。例如ArrayList、HashMap等。
不管调用端使用了什么同步措施,这段代码都无法在多线程环境下使用。
但在Java语言中这种代码是很少出现的。
同步是指多个线程并发访问共享数据的时候,保证共享数据在同一个时刻只被一条(或者是一些,当使用信号量的时候)线程使用。而互斥,是实现同步的一种手段,临界区(Critical Section)、互斥量(Mutex)和信号量(Semaphore)都是常见的互斥实现方法。
在Java里,最基本的使用互斥同步的手段就是使用synchronized关键字,这是一种块结构的同步语法。
synchronized关键字经过Javac编译后,会在同步块的前后分别形成monitorenter和monitorexit两个字节码指令。这两个字节码指令都需要一个reference类型的参数来指明锁定和解锁的对象。如果Java代码中的synchronized指定了对象参数,那么就以这个对象引用作为reference;如果没有明确指定,就根据synchronized修饰的方法是实例方法还是静态方法来取调用实例或者Class对象来作为锁。
synchronized:
在执行monitorenter指令时,首先要尝试获取对象的锁,如果这个对象没被锁定,或者当前线程已经持有了对象的锁,就把锁的计数器的值加1,而执行monitorexit指令时会将锁的计数器减1。一旦计数器的值为0,锁就被释放了。如果获取对象锁失败,那当前对象就应当被阻塞等待,直到锁被持有它的线程释放为止。
推论:
被synchronized修饰的同步块对同一条线程来说是可重入的;
持有对象锁的线程在释放锁之前,会阻塞其他线程的进入,直到释放锁。
缺点:
从执行成本来看,持有锁是一个重量级操作,因为Java的线程实现是1:1映射到系统内核线程的,如果阻塞或者切换线程,就需要产生系统调用从用户态切换到内核态。如果同步块代码特别简单,线程切换带来的开销甚至比执行代码本身还要大。
而虚拟机本身也会进行一些优化,例如在通知操作系统阻塞线程之前加入一段自旋等待过程,避免频繁地切换线程。
ReentrantLock:
Java提供了java.util.concurrent包下的Lock接口,让用户以非块结构来实现互斥同步。
重入锁(ReentrantLock)是Lock接口最常见的一种实现,它也是可重入的,相比于synchronized,ReentrantLock增加了一些高级功能。
1)等待可中断:当前持有锁的线程长期不释放锁时,正在等待的线程可以放弃等待,处理其他的事情
2)公平锁:多个线程在等待一个锁时,必须按照申请锁的顺序来依次获取锁,而非公平锁不保证这一点,例如synchronized。不过公平锁会导致ReentrantLock的性能急剧下降。
3)锁绑定多个条件:一个ReentrantLock对象可以同时绑定多个Condition对象。
可以看到,JDK5多线程环境下(对synchronized优化之前),Lock锁的性能极大优于Sync。
在JDK6对synchronized进行优化之后,二者的性能就差不多了,虽然Lock的高级性能更多,但并非synchronized就应该被放弃。
Lock应该确保在finally块中手动释放锁,避免同步保护的代码块抛出异常后导致永远不释放锁。这一点需要开发者自行保证,而synchronized即使抛出了异常,虚拟机也能保证正确释放锁。
互斥同步主要面临的问题是线程阻塞和唤醒带来的性能开销,因此也称为阻塞同步。互斥同步也是一种悲观的并发策略。无论共享数据是否出现竞争,互斥同步都会进行加锁,将会导致用户态到内核态的切换等开销。实际上有很多情况都会带来不必要的加锁。
有另一种选择:基于冲突检测的乐观并发策略。
通俗来说就是不管风险,先进行操作,如果没有其他线程争用共享数据,那操作就直接成功了;如果产生了冲突,再进行其他补偿措施。
这种乐观并发策略不再需要把线程阻塞挂起,称为非阻塞同步。
但使用这种并发方式是有前提的:那就是操作和冲突检测必须具有原子性。
怎么来保证原子性?靠硬件来保证。
有一些处理器指令就是原子性的:
测试和设置(Test-and-Set)
交换(Swap)
比较并交换(Compare-and-Swap),称CAS
例如之前使用过20个线程自增10000次操作来证明volatile变量不具备原子性,那么如何才能确保自增10000次的正确性呢?
解决的办法之一就是使用原子类的方法
- public class AtomicTest {
-
- public static AtomicInteger race = new AtomicInteger(0);
-
- public static void increase(){
- race.incrementAndGet();
- }
-
- public static final int THREAD_COUNT = 20;
-
- public static void main(String[] args) throws Exception{
- Thread[] threads = new Thread[THREAD_COUNT];
- for(int i = 0; i < THREAD_COUNT; i++){
- threads[i] = new Thread(new Runnable() {
- @Override
- public void run() {
- for(int i = 0; i < 10000; i++){
- increase();
- }
- }
- });
- threads[i].start();
- }
-
- while (Thread.activeCount() > 1) Thread.yield();
- System.out.println(race); // 200000
- }
- }
能正确得到结果都要归功于incrementAndGet()的原子性。
- /**
- * Atomically increments by one the current value.
- *
- * @return the updated value
- */
- public final int incrementAndGet() {
- return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
- }
-
- public final int getAndAddInt(Object var1, long var2, int var4) {
- int var5;
- do {
- var5 = this.getIntVolatile(var1, var2);
- } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
-
- return var5;
- }
但这也可能带来ABA问题,如果需要解决ABA问题,改用传统的互斥同步可能更为高效。
如果一个方法不涉及操作共享数据,那么自然就不需要任何方式去保证正确性。
如果一个变量要被多线程访问,可以将它用volatile关键字声明为”易变的“,但这个关键字的修改不能依赖于他本身。
每一个线程的Thread对象中都有一个ThreadLocalMap对象,存储了以ThreadLocal.threadLocalHashCode为K,本地线程变量为V的K-V键值对。ThreadLocal对象就是这个Map的访问入口。