Skip to content

Latest commit

 

History

History
202 lines (127 loc) · 10.4 KB

并发.md

File metadata and controls

202 lines (127 loc) · 10.4 KB
Raw

Java并发

[TOC]

线程安全与数据同步

synchronized关键字

synchronized可以用于对代码块或方法进行修饰，而不能用于对类和变量进行修饰

  1. 同步方法：

    （public)  synchronized (static) type method()

  2. 同步代码块：

    private final Object MUTEX = new Object();
private void sync(){
	sychronized(MUTEX){
		...
	}
}

深入sychronized关键字

  • 某线程获取了与MUTEX关联的monitor锁

  • 使用sychronized需要注意的问题：

    1. monitor关联的对象不能为空

      private final Object MUTEX = null;
private void sync(){
	sychronized(MUTEX){
		...
	}
}

    2. 所有代码会串行在sychronized保护的区域。作用域太大丧失并行的优势。

    3. 不同的monitor不能锁一个方法。

深入理解volatile

java内存模型

img

  • 共享变量存储于主内存之中，每个线程都可以访问
  • 每个线程私有的工作内存或者称为本地内存
  • 工作内存只存储该线程对共享变量的副本
  • 线程不能直接操作主内存，操作工作内存之后才能写入主内存
  • 工作内存和Java内存模型一样是个抽象概念，其实不存在

并发编程的三个重要特性

1.原子性

- 多个原子性的操作在一起不再是原子性。
- **volatile不保证原子性。**

2.可见性

		- 使用volatile：当一个变量被volatile修饰，对于共享变量的读操作会在主内存中进行，写操作先修改工作内存，然后立即刷新到主内存。
		- 使用synchronized:一个线程获得锁，执行同步方法
		- JUC提供的显示锁lock

3.有序性

  • volatile
  • sychronized
  • Lock显示锁

线程池

1、线程池的优势

  1. 降低系统资源消耗，通过重用已存在的线程，降低线程创建和销毁造成的消耗；
  2. 提高系统响应速度，当有任务到达时，通过复用已存在的线程，无需等待新线程的创建便能立即执行；
  3. 方便线程并发数的管控。因为线程若是无限制的创建，可能会导致内存占用过多而产生OOM，并且会造成cpu过度切换（cpu切换线程是有时间成本的（需要保持当前执行线程的现场，并恢复要执行线程的现场））。
  4. 提供更强大的功能，延时定时线程池。

2、线程池主要参数

  1. corePoolSize（线程池基本大小）：当向线程池提交一个任务时，若线程池已创建的线程数小于corePoolSize，即便此时存在空闲线程，也会通过创建一个新线程来执行该任务，直到已创建的线程数大于或等于corePoolSize时，（除了利用提交新任务来创建和启动线程（按需构造），也可以通过 prestartCoreThread() 或 prestartAllCoreThreads() 方法来提前启动线程池中的基本线程。
  2. maximumPoolSize（线程池最大大小）：线程池所允许的最大线程个数。当队列满了，且已创建的线程数小于maximumPoolSize，则线程池会创建新的线程来执行任务。另外，对于无界队列，可忽略该参数。
  3. keepAliveTime（线程存活保持时间）当线程池中线程数大于核心线程数时，线程的空闲时间如果超过线程存活时间，那么这个线程就会被销毁，直到线程池中的线程数小于等于核心线程数。
  4. workQueue（任务队列）：用于传输和保存等待执行任务的阻塞队列。
  5. threadFactory（线程工厂）：用于创建新线程。threadFactory创建的线程也是采用new Thread()方式，threadFactory创建的线程名都具有统一的风格：pool-m-thread-n（m为线程池的编号，n为线程池内的线程编号）。
  6. handler（线程饱和策略）：当线程池和队列都满了，再加入线程会执行此策略。

3、线程池流程

线程池流程

image-20210222102632061

  1. 判断核心线程池是否已满，没满则创建一个新的工作线程来执行任务。已满则。
  2. 判断任务队列是否已满，没满则将新提交的任务添加在工作队列，已满则。
  3. 判断整个线程池是否已满，没满则创建一个新的工作线程来执行任务，已满则执行饱和策略。

4、线程池为什么需要使用（阻塞）队列？

回到了非线程池缺点中的第3点：

  1. 因为线程若是无限制的创建，可能会导致内存占用过多而产生OOM，并且会造成cpu过度切换。 另外回到了非线程池缺点中的第1点：
  2. 创建线程池的消耗较高。 或者下面这个网上并不高明的回答：
  3. 线程池创建线程需要获取mainlock这个全局锁，影响并发效率，阻塞队列可以很好的缓冲。

5、线程池为什么要使用阻塞队列而不使用非阻塞队列？

阻塞队列可以保证任务队列中没有任务时阻塞获取任务的线程，使得线程进入wait状态，释放cpu资源。 当队列中有任务时才唤醒对应线程从队列中取出消息进行执行。 使得在线程不至于一直占用cpu资源。 （线程执行完任务后通过循环再次从任务队列中取出任务进行执行，代码片段如下 while (task != null || (task = getTask()) != null) {}）。 不用阻塞队列也是可以的，不过实现起来比较麻烦而已，有好用的为啥不用呢？

6、如何配置线程池

CPU密集型任务 尽量使用较小的线程池，一般为CPU核心数+1。 因为CPU密集型任务使得CPU使用率很高，若开过多的线程数，会造成CPU过度切换。 IO密集型任务 可以使用稍大的线程池，一般为2*CPU核心数。 IO密集型任务CPU使用率并不高，因此可以让CPU在等待IO的时候有其他线程去处理别的任务，充分利用CPU时间。 混合型任务 可以将任务分成IO密集型和CPU密集型任务，然后分别用不同的线程池去处理。 只要分完之后两个任务的执行时间相差不大，那么就会比串行执行来的高效。 因为如果划分之后两个任务执行时间有数据级的差距，那么拆分没有意义。 因为先执行完的任务就要等后执行完的任务，最终的时间仍然取决于后执行完的任务，而且还要加上任务拆分与合并的开销，得不偿失。

7、java中提供的线程池

Executors类提供了4种不同的线程池：newCachedThreadPool, newFixedThreadPool, newScheduledThreadPool, newSingleThreadExecutor

8、execute()和submit()方法

  1. execute()，执行一个任务，没有返回值。

  2. submit()，提交一个线程任务，有返回值。

    submit(Callable<T> task)能获取到它的返回值，通过future.get()获取（阻塞直到任务执行完）。一般使用FutureTask+Callable配合使用（IntentService中有体现）。 submit(Runnable task, T result)能通过传入的载体result间接获得线程的返回值。 submit(Runnable task)则是没有返回值的，就算获取它的返回值也是null。 Future.get方法会使取结果的线程进入阻塞状态，知道线程执行完成之后，唤醒取结果的线程，然后返回结果。

多线程下Map讨论

多线程下安全的操作map，三种方法：

  1. 使用Hashtable线程安全类；
  2. 使用Collections.synchronizedMap方法，对方法进行加同步锁；
  3. 使用并发包中的ConcurrentHashMap类；

Hashtable

Hashtable 是一个线程安全的类，Hashtable 几乎所有的添加、删除、查询方法都加了synchronized同步锁！ 相当于给整个哈希表加了一把大锁，多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞等待需要的锁被释放，在竞争激烈的多线程场景中性能就会非常差，所以 Hashtable 不推荐使用！

image-20210223103555767

synchronizedMap

再来看看第二种方法，使用Collections.synchronizedMap方法，我们打开 JDK 源码，部分内容如下：

img

可以很清晰的看到，如果传入的是 HashMap 对象，其实也是对 HashMap 做的方法做了一层包装，里面使用对象锁来保证多线程场景下，操作安全，本质也是对 HashMap 进行全表锁！

使用Collections.synchronizedMap方法，在竞争激烈的多线程环境下性能依然也非常差，所以不推荐使用！

上面 2 种方法，由于都是对方法进行全表锁，所以在多线程环境下容易造成性能差的问题，因为** hashMap 是数组 + 链表的数据结构，如果我们把数组进行分割多段，对每一段分别设计一把同步锁，这样在多线程访问不同段的数据时，就不会存在锁竞争了，这样是不是可以有效的提高性能？**

ConcurrentHashMap

ConcurrentHashMap 类所采用的正是分段锁的思想，将 HashMap 进行切割，把 HashMap 中的哈希数组切分成小数组，每个小数组有 n 个 HashEntry 组成，其中小数组继承自ReentrantLock（可重入锁），这个小数组名叫Segment， 如下图：

image-20210223114026595

当然，JDK1.7 和 JDK1.8 对 ConcurrentHashMap 的实现有很大的不同！ JDK1.8 对 HashMap 做了改造，当冲突链表长度大于 8 时，会将链表转变成红黑树结构，上图是 ConcurrentHashMap 的整体结构，参考 JDK1.7！ 我们再来看看 JDK1.8 中 ConcurrentHashMap 的整体结构，内容如下：

image-20210223114102526

JDK1.8 中 ConcurrentHashMap 类取消了 Segment 分段锁，采用 CAS + synchronized 来保证并发安全，数据结构跟 jdk1.8 中 HashMap 结构类似，都是数组 + 链表（当链表长度大于 8 时，链表结构转为红黑二叉树）结构。 ConcurrentHashMap 中 synchronized 只锁定当前链表或红黑二叉树的首节点，只要节点 hash 不冲突，就不会产生并发，相比 JDK1.7 的 ConcurrentHashMap 效率又提升了 N 倍！。