Juc（读写锁，集合）

最新推荐文章于 2024-08-24 18:06:23 发布

码ming

最新推荐文章于 2024-08-24 18:06:23 发布

阅读量294

点赞数 1

分类专栏： Java进阶文章标签： java 并发编程多线程

本文链接：https://blog.csdn.net/weixin_46168350/article/details/117033399

版权

Java进阶专栏收录该内容

11 篇文章 0 订阅

订阅专栏

Java JUC 简介

在Java 5.0 提供了java.util.concurrent（简称JUC ）包，在此包中增加了在并发编程中很常用的实用工具类，用于定义类似于线程的自定义子系统，包括线程池、异步IO 和轻量级任务框架。提供可调的、灵活的线程池。还提供了设计用于多线程上下文中的Collection 实现等。

集合的线程安全

用Vector

1.线程安全与线程不安全集合
集合类型中存在线程安全与线程不安全的两种,常见例如:
ArrayList ----- Vector
HashMap -----HashTable
但是以上都是通过synchronized关键字实现,效率较低

Collections

Collections提供了方法synchronizedList保证list是同步线程安全的

public static void main(String[] args) { 
List list = Collections.synchronizedList(new ArrayList<>());
 for (int i = 0; i < 100; i++) { 
 new Thread(() ->{ list.add(UUID.randomUUID().toString()); System.out.println(list); }, "线程" + i).start(); 
 }
 }

用JUC下的CopyOnWriteArrayList(重点)

首先我们对CopyOnWriteArrayList进行学习,其特点如下:
它相当于线程安全的ArrayList。和ArrayList一样，它是个可变数组；但是和ArrayList不同的时，它具有以下特性：

它最适合于具有以下特征的应用程序：List 大小通常保持很小，只读操作远多于可变操作，需要在遍历期间防止线程间的冲突。
它是线程安全的。
因为通常需要复制整个基础数组，所以可变操作（add()、set() 和 remove() 等等）的开销很大。
迭代器支持hasNext(), next()等不可变操作，但不支持可变 remove()等操作。
使用迭代器进行遍历的速度很快，并且不会与其他线程发生冲突。在构造迭代器时，迭代器依赖于不变的数组快照。
独占锁效率低：采用读写分离思想解决
写线程获取到锁，其他写线程阻塞
复制思想：

当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行 Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。
这时候会抛出来一个新的问题，也就是数据不一致的问题。如果写线程还没来得及写会内存，其他的线程就会读到了脏数据。
这就是CopyOnWriteArrayList 的思想和原理。就是拷贝一份。

原因分析(重点):动态数组与线程安全
下面从“动态数组”和“线程安全”两个方面进一步对CopyOnWriteArrayList的原理进行说明。

“动态数组”机制
- 它内部有个“volatile数组”(array)来保持数据。在“添加/修改/删除”数据时，都会新建一个数组，并将更新后的数据拷贝到新建的数组中，最后再将该数组赋值给“volatile数组”, 这就是它叫做CopyOnWriteArrayList的原因
- 由于它在“添加/修改/删除”数据时，都会新建数组，所以涉及到修改数据的操作，CopyOnWriteArrayList效率很低；但是单单只是进行遍历查找的话，效率比较高。
“线程安全”机制
- 通过volatile和互斥锁来实现的。
- 通过“volatile数组”来保存数据的。一个线程读取volatile数组时，总能看到其它线程对该volatile变量最后的写入；就这样，通过volatile提供了“读取到的数据总是最新的”这个机制的保证。
- 通过互斥锁来保护数据。在“添加/修改/删除”数据时，会先“获取互斥锁”，再修改完毕之后，先将数据更新到“volatile数组”中，然后再“释放互斥锁”，就达到了保护数据的目的。

总结：

线程安全，读操作时无锁的ArrayList
底层数据结构是一个Object[]，初始容量为0，之后每增加一个元素，容量+1，数组复制一遍
增删改上锁、读不上锁
遍历过程由于遍历的只是全局数组的一个副本，即使全局数组发生了增删改变化，副本也不会变化，所以不会发生并发异常
读多写少且脏数据影响不大的并发情况下，选择CopyOnWriteArrayList

读操作会发生脏读，为什么？

从类属性部分，我们可以看到array数组是volatile修饰的，也就是当你对volatile进行写操作后，会将写过后的array数组强制刷新到主内存，在读操作中，当你读出数组（即getArray()）时，会强制从主内存将array读到工作内存，所以应该不会发生脏读才对呀！！！

还有：CopyOnWriteArraySet，ConcurrentHashMap

ConcurrentHashMap

Java 5.0 在java.util.concurrent包中提供了多种并发容器类来改进同步容器的性能。
ConcurrentHashMap 同步容器类是Java 5 增加的一个线程安全的哈希表。对与多线程的操作，介于HashMap 与Hashtable 之间。内部采用“锁分段”机制替代Hashtable 的独占锁。进而提高性能。
此包还提供了设计用于多线程上下文中的Collection 实现：ConcurrentHashMap、ConcurrentSkipListMap、ConcurrentSkipListSet、CopyOnWriteArrayList 和CopyOnWriteArraySet。当期望许多线程访问一个给定collection 时，ConcurrentHashMap 通常优于同步的HashMap，ConcurrentSkipListMap 通常优于同步的TreeMap。当期望的读数和遍历远远大于列表的更新数时，CopyOnWriteArrayList 优于同步的ArrayList。

private static CopyOnWriteArrayList<String> list = new CopyOnWriteArrayList<>();

各种锁

1、公平锁、非公平锁

公平锁：非常公平，不能够插队，必须先来后到！
非公平锁：非常不公平，可以插队（默认都是非公平）

public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}

ReentrantLock(ture) 公平锁

ReentrantLock(false) 非公平锁

2、可重入锁

可重入锁（递归锁）

拿到外面的锁后里面的锁自动获得

Synchronized

// Synchronized
public class Demo01 {
	public static void main(String[] args) {
        Phone phone = new Phone();
        new Thread(()->{
        	phone.sms();
        },"A").start();
        
        new Thread(()->{
       		 phone.sms();
        },"B").start();
        }
}
class Phone{
public synchronized void sms(){
    System.out.println(Thread.currentThread().getName() + "sms");
        call(); // 这里也有锁
}
public synchronized void call(){
	System.out.println(Thread.currentThread().getName() + "call");
}
}

lock

public class Demo02 {
public static void main(String[] args) {
    Phone2 phone = new Phone2();
        new Thread(()->{
            phone.sms();
        },"A").start();
        
            new Thread(()->{
                  phone.sms();
            },"B").start();
    }
}
class Phone2{
    Lock lock = new ReentrantLock();
    public void sms(){
        lock.lock(); // 细节问题：lock.lock(); lock.unlock(); // lock 锁必须配对，否则就会死在里面
        lock.lock();
        try {
            System.out.println(Thread.currentThread().getName() + "sms");
            call(); // 这里也有锁
        } catch (Exception e) {
       		 e.printStackTrace();
        } finally {
            lock.unlock();
            lock.unlock();
        }
    }
        public void call(){
        	lock.lock();
            try {
            System.out.println(Thread.currentThread().getName() + "call");
            } catch (Exception e) {
                 e.printStackTrace();
            } finally {
            lock.unlock();
            }
        }
}

3、闭锁

闭锁可以延迟线程的进度直到其到达终止状态，闭锁可以用来确保某些活动直到其他活动都完成才继续执行：
- 确保某个计算在其需要的所有资源都被初始化之后才继续执行;
- 确保某个服务在其依赖的所有其他服务都已经启动之后才启动;
- 等待直到某个操作所有参与者都准备就绪再继续执行。

4、悲观锁、乐观锁

1、悲观锁

顾名思义，就是比较悲观的锁，总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。（有点像串行化）

2、乐观锁

反之，总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。（可以并发）

使用场景

乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
乐观锁适用于读比较少的情况下（多写场景），如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

5、表锁，行锁

表锁：锁住整张表
行锁：锁住一行，会发生死锁

自旋锁

如果在获取自旋锁时，没有任何执行单元保持该锁，那么将立即得到锁；如果在获取自旋锁时锁已经有保持者，那么获取锁操作将自旋在那里，直到该自旋锁的保持者释放了锁。

缺点

\1. 如果某个线程持有锁的时间过长，就会导致其它等待获取锁的线程进入循环等待，消耗CPU。使用不当会造成CPU使用率极高。

\2. 上面Java实现的自旋锁不是公平的，即无法满足等待时间最长的线程优先获取锁。不公平的锁就会存在“线程饥饿”问题。

优点

自旋锁不会使线程状态发生切换，一直处于用户态，即线程一直都是active的；不会使线程进入阻塞状态，减少了不必要的上下文切换，执行速度快

非自旋锁在获取不到锁的时候会进入阻塞状态，从而进入内核态，当获取到锁的时候需要从内核态恢复，需要线程上下文切换。（线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能）

案例

public class SpinLock {

private AtomicReference cas = new AtomicReference();

public void lock() {

Thread current = Thread.currentThread();

// 利用CAS

while (!cas.compareAndSet(null, current)) {

// DO nothing

}

}

public void unlock() {

Thread current = Thread.currentThread();

cas.compareAndSet(current, null);

}

}

读-写锁ReadWriteLock

ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有writer，读取锁可以由多个reader 线程同时保持。写入锁是独占的。。
ReadWriteLock 读取操作通常不会改变共享资源，但执行写入操作时，必须独占方式来获取锁。对于读取操作占多数的数据结构。ReadWriteLock 能提供比独占锁更高的并发性。而对于只读的数据结构，其中包含的不变性可以完全不需要考虑加锁操作。
JAVA的并发包提供了读写锁ReentrantReadWriteLock，它表示两个锁，一个是读操作相关的锁，称为共享锁；一个是写相关的锁，称为排他锁

线程进入读锁的前提条件：
• 没有其他线程的写锁
• 没有写请求, 或者有写请求，但调用线程和持有锁的线程是同一个(可重入锁)。
线程进入写锁的前提条件：
• 没有其他线程的读锁
• 没有其他线程的写锁

而读写锁有以下三个重要的特性：
（1）公平选择性：支持非公平（默认）和公平的锁获取方式，吞吐量还是非公平优于公平。
（2）重进入：读锁和写锁都支持线程重进入。
（3）锁降级：遵循获取写锁、获取读锁再释放写锁的次序，写锁能够降级成为读锁。

已知实现类：ReentrantReadWriteLock

读锁：共享锁,多个线程可以同时占有

写锁：独占锁, 一次只能被一个线程占有

读-读可以共存！
读-写不能共存！
写-写不能共存！

演示读写锁降级

//演示读写锁降级
public class Demo1 {

    public static void main(String[] args) {
        //可重入读写锁对象
        ReentrantReadWriteLock rwLock = new ReentrantReadWriteLock();
        ReentrantReadWriteLock.ReadLock readLock = rwLock.readLock();//读锁
        ReentrantReadWriteLock.WriteLock writeLock = rwLock.writeLock();//写锁

        //锁降级
       //1 获取写锁
        writeLock.lock();
        System.out.println("atguigu");
        
        //2 获取读锁
        readLock.lock();
        System.out.println("---read");



        //3 释放写锁
        //writeLock.unlock();

        //4 释放读锁
        //readLock.unlock();
    }
}

总结

写能降级读
读不能升级为写
可以先写后读，上面1，2位置不能调换

/*
 * 1. ReadWriteLock : 读写锁
 * 
 * 写写/读写 需要“互斥”
 * 读读 不需要互斥
 * 
 */
public class TestReadWriteLock {

	public static void main(String[] args) {
		ReadWriteLockDemo rw = new ReadWriteLockDemo();
		
		new Thread(new Runnable() {
			
			@Override
			public void run() {
				rw.set((int)(Math.random() * 101));
			}
		}, "Write:").start();
		
		
		for (int i = 0; i < 100; i++) {
			new Thread(new Runnable() {
				
				@Override
				public void run() {
					rw.get();
				}
			}).start();
		}
	}
	
}

class ReadWriteLockDemo{
	
	private int number = 0;
	
	private ReadWriteLock lock = new ReentrantReadWriteLock();
	
	//读
	public void get(){
		lock.readLock().lock(); //上锁
		
		try{
			System.out.println(Thread.currentThread().getName() + " : " + number);
		}finally{
			lock.readLock().unlock(); //释放锁
		}
	}
	
	//写
	public void set(int number){
		lock.writeLock().lock();
		
		try{
			System.out.println(Thread.currentThread().getName());
			this.number = number;
		}finally{
			lock.writeLock().unlock();
		}
	}
}

缺点：

（1）：造成锁饥饿，一直读，没有写
（2）：读的时候不能写，只有读完成之后才可以写，写操作时可以读（锁降级）

读的时候会发生死锁
由于锁降级：
1线程修改时候,需要等待2线程读之后
2线程修改时候，需要等1线程读之后
在这里插入图片描述

写的操作会发生死锁
在这里插入图片描述
线程1写一号资源，在写二号资源（一被占用）
线程2写二号资源，在写一号资源（二被占用）

阻塞队列

Concurrent包中，BlockingQueue很好的解决了多线程中，如何高效安全“传输”数据的问题。通过这些高效并且线程安全的队列类，为我们快速搭建高质量的多线程程序带来极大的便利。

阻塞队列，顾名思义，首先它是一个队列, 通过一个共享的队列，可以使得数据由队列的一端输入，从另外一端输出；

当队列是空的，从队列中获取元素的操作将会被阻塞
当队列是满的，从队列中添加元素的操作将会被阻塞
试图从空的队列中获取元素的线程将会被阻塞，直到其他线程往空的队列插入新的元素
试图向已满的队列中添加新元素的线程将会被阻塞，直到其他线程从队列中移除一个或多个元素或者完全清空，使队列变得空闲起来并后续新增

常用的队列主要有以下两种：

先进先出（FIFO）：先插入的队列的元素也最先出队列，类似于排队的功能。从某种程度上来说这种队列也体现了一种公平性
后进先出（LIFO）：后插入队列的元素最先出队列，这种队列优先处理最近发生的事件(栈)
在多线程领域：所谓阻塞，在某些情况下会挂起线程（即阻塞），一旦条件满足，被挂起的线程又会自动被唤起

为什么需要BlockingQueue

好处是我们不需要关心什么时候需要阻塞线程，什么时候需要唤醒线程，因为这一切BlockingQueue都给你一手包办了
在concurrent包发布以前，在多线程环境下，我们每个程序员都必须去自己控制这些细节，尤其还要兼顾效率和线程安全，而这会给我们的程序带来不小的复杂度。
多线程环境中，通过队列可以很容易实现数据共享，比如经典的“生产者”和“消费者”模型中，通过队列可以很便利地实现两者之间的数据共享。假设我们有若干生产者线程，另外又有若干个消费者线程。如果生产者线程需要把准备好的数据共享给消费者线程，利用队列的方式来传递数据，就可以很方便地解决他们之间的数据共享问题。但如果生产者和消费者在某个时间段内，万一发生数据处理速度不匹配的情况呢？理想情况下，如果生产者产出数据的速度大于消费者消费的速度，并且当生产出来的数据累积到一定程度的时候，那么生产者必须暂停等待一下（阻塞生产者线程），以便等待消费者线程把累积的数据处理完毕，反之亦然。
当队列中没有数据的情况下，消费者端的所有线程都会被自动阻塞（挂起），直到有数据放入队列
当队列中填满数据的情况下，生产者端的所有线程都会被自动阻塞（挂起），直到队列中有空的位置，线程被自动唤醒