Java线程安全与锁机制

最新推荐文章于 2024-04-07 21:30:04 发布

外星喵

最新推荐文章于 2024-04-07 21:30:04 发布

阅读量713

点赞数 3

分类专栏：并发编程与网络通信文章标签：多线程 java 线程安全锁内存屏障

本文链接：https://blog.csdn.net/c15158032319/article/details/103055544

版权

并发编程与网络通信专栏收录该内容

28 篇文章 2 订阅

订阅专栏

什么是线程安全性

当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些进程将如何交替执行，并且在主调代码中不需要任何额外的同步或协同，这个类都能表现出正确的行为，那么就称这个类就是线程安全的。

线程安全的三大基石

原子性：提供互斥访问，同一时刻只能有一个线程对共享资源进行操作（Atomic、CAS算法、synchronized、Lock等）
可见性：一个主内存的线程如果对共享数据进行了修改，可以及时被其他线程观察到（synchronized、volatile）
有序性：如果两个线程不能从 happens-before原则观察出来，那么就不能观察他们的有序性，虚拟机可以随意的对他们进行重排序，导致其观察观察结果杂乱无序（happens-before原则）

产生线程安全问题的原因

只有能够相互通讯的线程才会产生线程安全的问题，关于线程通讯请参考Java多线程通讯

可见性问题

在这里插入图片描述

左边CPU中运行的线程从主存中拷贝共享对象obj到它的CPU缓存，把对象obj的count变量改为2。但这个变更对运行在右边CPU中的线程不可见，因为这个更改还没有flush到主存中

在多线程的环境下，如果某个线程首次读取共享变量，则首先到主内存中获取该变量，然后存入工作内存中，以后只需要在工作内存中读取该变量即可。同样如果对该变量执行了修改的操作，则先将新值写入工作内存中，然后再刷新至主内存中。但是什么时候最新的值会被刷新至主内存中是不太确定，一般来说会很快，但具体时间不知

要解决共享对象可见性这个问题，我们可以使用volatile关键字或者是加锁

竞争问题

在这里插入图片描述

重排序

重排序类型

除了共享内存和工作内存带来的问题，还存在重排序的问题：在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。
重排序分3种类型

编译器优化的重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序：现代处理器采用了指令级并行技术（Instruction-LevelParallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序：由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

as-if-serial

as-if-serial语义的意思是：不管怎么重排序，（单线程）程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义

保障线程安全的规则

内存屏障

Java编译器在生成指令序列的适当位置会插入内存屏障指令来禁止特定类型的处理器重排序，从而让程序按我们预想的流程去执行。

1、保证特定操作的执行顺序

2、影响某些数据（或则是某条指令的执行结果）的内存可见性

编译器和CPU能够重排序指令，保证最终相同的结果，尝试优化性能。插入一条Memory Barrier会告诉编译器和CPU：不管什么指令都不能和这条Memory Barrier指令重排序

Memory Barrier所做的另外一件事是强制刷出各种CPU cache，如一个Write-Barrier（写入屏障）将刷出所有在Barrier之前写入 cache 的数据，因此，任何CPU上的线程都能读取到这些数据的最新版本。

内存屏障底层分为读屏障和写屏障，JMM又对读写屏障做了各种组合，分为了Loadload、Storestore、LoadStore、StoreLoad

Happens-Before规则

happens-before是JVM规定重排序必须遵守的规则
JMM为我们提供了以下的Happens-Before规则：

程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作
监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁
volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读
传递性：如果A happens-before B，且B happens-before C，那么A happens-before C
start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作
join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回
线程中断规则：对线程interrupt方法的调用happens-before于被中断线程的代码检测到中断事件的发生

Java锁的介绍

锁状态的分类

Java 语言专门针对 synchronized 关键字设置了四种状态，它们分别是：

无锁
偏向锁
轻量级锁
重量级锁

但是在了解这些锁之前还需要先了解一下 Java 对象头和 Monitor。

Java 对象头

我们知道 synchronized 是悲观锁，在操作同步之前需要给资源加锁，这把锁就是对象头里面的，而Java 对象头又是什么呢？我们以 Hotspot 虚拟机为例，Hopspot 对象头主要包括两部分数据：Mark Word（标记字段）和 class Pointer（类型指针）。

Mark Word：默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。

class Point：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

在32位虚拟机和64位虚拟机的 Mark Word 所占用的字节大小不一样，32位虚拟机的 Mark Word 和 class Pointer 分别占用 32bits 的字节，而 64位虚拟机的 Mark Word 和 class Pointer 占用了64bits 的字节，下面我们以 32位虚拟机为例，来看一下其 Mark Word 的字节具体是如何分配的
在这里插入图片描述
无状态也就是无锁的时候，对象头开辟 25bit 的空间用来存储对象的 hashcode ，4bit 用于存放分代年龄，1bit 用来存放是否偏向锁的标识位，2bit 用来存放锁标识位为01
偏向锁中划分更细，还是开辟25bit 的空间，其中23bit 用来存放线程ID，2bit 用来存放 epoch，4bit 存放分代年龄，1bit 存放是否偏向锁标识， 0表示无锁，1表示偏向锁，锁的标识位还是01
轻量级锁中直接开辟 30bit 的空间存放指向栈中锁记录的指针，2bit 存放锁的标志位，其标志位为00
重量级锁中和轻量级锁一样，30bit 的空间用来存放指向重量级锁的指针，2bit 存放锁的标识位，为11
GC标记开辟30bit 的内存空间却没有占用，2bit 空间存放锁标志位为11。
其中无锁和偏向锁的锁标志位都是01，只是在前面的1bit区分了这是无锁状态还是偏向锁状态。

锁的意义

加锁主要是为了解决在多线程环境下可能遇到的共享资源使用过程中产生冲突的问题。多个线程同时对一个资源进行访问时，如果不加锁会造成线程安全问题，比如一个线程读到了另一个线程的脏数据得出一个错误的结果。

Java锁的分类

从线程是否需要对资源加锁可以分为悲观锁和乐观锁
从资源已被锁定，线程是否阻塞可以分为自旋锁
从多个线程并发访问资源，也就是 Synchronized 可以分为无锁、偏向锁、轻量级锁和重量级锁
从锁的公平性进行区分，可以分为公平锁和非公平锁
从根据锁是否重复获取可以分为可重入锁和不可重入锁
从那个多个线程能否获取同一把锁分为共享锁和排他锁

重入锁

锁作为并发共享数据，保证一致性的工具，在JAVA平台有多种实现(如
synchronized（重量级）和 ReentrantLock(轻量级)等等 )
。这些已经写好提供的锁为我们开发提供了便利。

重入锁，也叫做递归锁，指的是同一线程外层函数获得锁之后
，内层递归函数仍然有获取该锁的代码，但不受影响。
在JAVA环境下 ReentrantLock 和synchronized 都是可重入锁

public class Test implements Runnable {
	public  synchronized void get() {
		System.out.println("name:" + Thread.currentThread().getName() + " get();");
		set();
	}

	public synchronized  void set() {
		System.out.println("name:" + Thread.currentThread().getName() + " set();");
	}

	@Override

	public void run() {
		get();
	}

	public static void main(String[] args) {
		Test ss = new Test();
		new Thread(ss).start();
		new Thread(ss).start();
		new Thread(ss).start();
		new Thread(ss).start();
	}
}

public class Test02 extends Thread {
	ReentrantLock lock = new ReentrantLock();
	public void get() {
		lock.lock();
		System.out.println(Thread.currentThread().getId());
		set();
		lock.unlock();
	}
	public void set() {
		lock.lock();
		System.out.println(Thread.currentThread().getId());
		lock.unlock();
	}
	@Override
	public void run() {
		get();
	}
	public static void main(String[] args) {
		Test ss = new Test();
		new Thread(ss).start();
		new Thread(ss).start();
		new Thread(ss).start();
	}

}

读写锁

相比Java中的锁(Locks in Java)里Lock实现，读写锁更复杂一些。假设你的程序中涉及到对一些共享资源的读和写操作，且写操作没有读操作那么频繁。在没有写操作的时候，两个线程同时读一个资源没有任何问题，所以应该允许多个线程能在同时读取共享资源。但是如果有一个线程想去写这些共享资源，就不应该再有其它线程对该资源进行读或写（译者注：也就是说：读-读能共存，读-写不能共存，写-写不能共存）。这就需要一个读/写锁来解决这个问题。Java5在java.util.concurrent包中已经包含了读写锁。尽管如此，我们还是应该了解其实现背后的原理。

public class Cache {
	static Map<String, Object> map = new HashMap<String, Object>();
	static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
	static Lock r = rwl.readLock();
	static Lock w = rwl.writeLock();

	// 获取一个key对应的value
	public static final Object get(String key) {
		r.lock();
		try {
			System.out.println("正在做读的操作,key:" + key + " 开始");
			Thread.sleep(100);
			Object object = map.get(key);
			System.out.println("正在做读的操作,key:" + key + " 结束");
			System.out.println();
			return object;
		} catch (InterruptedException e) {

		} finally {
			r.unlock();
		}
		return key;
	}

	// 设置key对应的value，并返回旧有的value
	public static final Object put(String key, Object value) {
		w.lock();
		try {

			System.out.println("正在做写的操作,key:" + key + ",value:" + value + "开始.");
			Thread.sleep(100);
			Object object = map.put(key, value);
			System.out.println("正在做写的操作,key:" + key + ",value:" + value + "结束.");
			System.out.println();
			return object;
		} catch (InterruptedException e) {

		} finally {
			w.unlock();
		}
		return value;
	}

	// 清空所有的内容
	public static final void clear() {
		w.lock();
		try {
			map.clear();
		} finally {
			w.unlock();
		}
	}

	public static void main(String[] args) {
		new Thread(new Runnable() {

			@Override
			public void run() {
				for (int i = 0; i < 10; i++) {
					Cache.put(i + "", i + "");
				}

			}
		}).start();
		new Thread(new Runnable() {

			@Override
			public void run() {
				for (int i = 0; i < 10; i++) {
					Cache.get(i + "");
				}

			}
		}).start();
	}
}

悲观锁、乐观锁

乐观锁

总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现。

version方式：一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

核心SQL语句

update table set x=x+1, version=version+1 where id=#{id} and
version=#{version};

CAS操作方式：即compare and swap 或者 compare and
set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。

悲观锁

总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁。

原子类

java.util.concurrent.atomic包：原子类的小工具包，支持在单个变量上解除锁的线程安全编程

原子变量类相当于一种泛化的 volatile
变量，能够支持原子的和有条件的读-改-写操作。AtomicInteger
表示一个int类型的值，并提供了 get 和 set 方法，这些 Volatile
类型的int变量在读取和写入上有着相同的内存语义。它还提供了一个原子的
compareAndSet 方法（如果该方法成功执行，那么将实现与读取/写入一个 volatile
变量相同的内存效果），以及原子的添加、递增和递减等方法。AtomicInteger
表面上非常像一个扩展的 Counter
类，但在发生竞争的情况下能提供更高的可伸缩性，因为它直接利用了硬件对并发的支持。

为什么会有原子类

CAS：Compare and Swap，即比较再交换。

jdk5增加了并发包java.util.concurrent.*,其下面的类使用CAS算法实现了区别于synchronouse同步锁的一种乐观锁。JDK
5之前Java语言是靠synchronized关键字保证同步的，这是一种独占锁，也是是悲观锁。

如果同一个变量要被多个线程访问，则可以使用该包中的类

AtomicBoolean

AtomicInteger

AtomicLong

AtomicReference

CAS无锁模式

什么是CAS

CAS：Compare and Swap，即比较再交换。

CAS算法理解

（1）与锁相比，使用比较交换（下文简称CAS）会使程序看起来更加复杂一些。但由于其非阻塞性，它对死锁问题天生免疫，并且，线程间的相互影响也远远比基于锁的方式要小。更为重要的是，使用无锁的方式完全没有锁竞争带来的系统开销，也没有线程间频繁调度带来的开销，因此，它要比基于锁的方式拥有更优越的性能。

（2）无锁的好处：

第一，在高并发的情况下，它比有锁的程序拥有更好的性能；

第二，它天生就是死锁免疫的。

就凭借这两个优势，就值得我们冒险尝试使用无锁的并发。

（3）CAS算法的过程是这样：它包含三个参数CAS(V,E,N):
V表示要更新的变量，E表示预期值，N表示新值。仅当V值等于E值时，才会将V的值设为N，如果V值和E值不同，则说明已经有其他线程做了更新，则当前线程什么都不做。最后，CAS返回当前V的真实值。

（4）CAS操作是抱着乐观的态度进行的，它总是认为自己可以成功完成操作。当多个线程同时使用CAS操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理，CAS操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。

（5）简单地说，CAS需要你额外给出一个期望值，也就是你认为这个变量现在应该是什么样子的。如果变量不是你想象的那样，那说明它已经被别人修改过了。你就重新读取，再次尝试修改就好了。

（6）在硬件层面，大部分的现代处理器都已经支持原子化的CAS指令。在JDK
5.0以后，虚拟机便可以使用这个指令来实现并发操作和并发数据结构，并且，这种操作在虚拟机中可以说是无处不在。

常用原子类

Java中的原子操作类大致可以分为4类：原子更新基本类型、原子更新数组类型、原子更新引用类型、原子更新属性类型。这些原子类中都是用了无锁的概念，有的地方直接使用CAS操作的线程安全的类型。

AtomicBoolean

AtomicInteger

AtomicLong

AtomicReference

public class Test0001 implements Runnable {
	private static Integer count = 1;
	private static AtomicInteger atomic = new AtomicInteger();

	@Override
	public void run() {
		while (true) {
			int count = getCountAtomic();
			System.out.println(count);
			if (count >= 150) {
				break;
			}
		}
	}

	public synchronized Integer getCount() {
		try {
			Thread.sleep(50);
		} catch (Exception e) {
			// TODO: handle exception
		}

		return count++;
	}

	public Integer getCountAtomic() {
		try {
			Thread.sleep(50);
		} catch (Exception e) {
			// TODO: handle exception
		}
		return atomic.incrementAndGet();
	}

	public static void main(String[] args) {
		Test0001 test0001 = new Test0001();
		Thread t1 = new Thread(test0001);
		Thread t2 = new Thread(test0001);
		t1.start();
		t2.start();
	}

}

CAS（乐观锁算法）的基本假设前提

CAS比较与交换的伪代码可以表示为：

do{
备份旧数据；
基于旧数据构造新数据；
}while(!CAS( 内存地址，备份的旧数据，新数据 ))

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TbQK21WG-1622463818192)(media/f99d6ac28ff0dc502dde48294ec9feb2.png)]

（上图的解释：CPU去更新一个值，但如果想改的值不再是原来的值，操作就失败，因为很明显，有其它操作先改变了这个值。）

就是指当两者进行比较时，如果相等，则证明共享数据没有被修改，替换成新值，然后继续往下运行；如果不相等，说明共享数据已经被修改，放弃已经所做的操作，然后重新执行刚才的操作。容易看出
CAS 操作是基于共享数据不会被修改的假设，采用了类似于数据库的 commit-retry
的模式。当同步冲突出现的机会很少时，这种假设能带来较大的性能提升。

public final int getAndAddInt(Object o, long offset, int delta) {
        int v;
        do {
            v = getIntVolatile(o, offset);
        } while (!compareAndSwapInt(o, offset, v, v + delta));
        return v;
    }

/** 
	 * Atomically increments by one the current value. 
	 * 
	 * @return the updated value 
	 */  
	public final int incrementAndGet() {  
	    for (;;) {  
	        //获取当前值  
	        int current = get();  
	        //设置期望值  
	        int next = current + 1;  
	        //调用Native方法compareAndSet，执行CAS操作  
	        if (compareAndSet(current, next))  
	            //成功后才会返回期望值，否则无线循环  
	            return next;  
	    }  
	}

CAS缺点

CAS存在一个很明显的问题，即ABA问题。

问题：如果变量V初次读取的时候是A，并且在准备赋值的时候检查到它仍然是A，那能说明它的值没有被其他线程修改过了吗？

如果在这段期间曾经被改成B，然后又改回A，那CAS操作就会误认为它从来没有被修改过。针对这种情况，java并发包中提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。

分布式锁

如果想在不同的jvm中保证数据同步，使用分布式锁技术。

有数据库实现、缓存实现、Zookeeper分布式锁

外星喵

关注

3
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
Java线程安全与锁机制

- 从线程是否需要对资源加锁可以分为悲观锁和乐观锁- 从资源已被锁定，线程是否阻塞可以分为自旋锁- 从多个线程并发访问资源，也就是 Synchronized 可以分为无锁、偏向锁、轻量级锁和重量级锁- 从锁的公平性进行区分，可以分为公平锁和非公平锁- 从根据锁是否重复获取可以分为可重入锁和不可重入锁- 从那个多个线程能否获取同一把锁分为共享锁和排他锁
复制链接

扫一扫