艾编程coding老师课堂笔记：java设计模式与并发编程笔记
设计模式概念
1.1 什么是设计模式
设计模式（Design Pattern）是前辈们对代码开发经验的总结，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。
1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。
这 23 种设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性，以及类的关联关系和组合关系的充分理解。
1.2 设计模式的概念与意义
有关软件设计模式的定义很多，有些从模式的特点来说明，有些从模式的作用来说明。
1. 软件设计模式的概念
软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
2. 学习设计模式的意义
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。
正确使用设计模式具有以下优点。
-
可以提高程序员的思维能力、编程能力和设计能力。
-
使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
-
使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
当然，软件设计模式只是一个引导。在具体的软件幵发中，必须根据设计的应用系统的特点和要求来恰当选择。对于简单的程序开发，苛能写一个简单的算法要比引入某种设计模式更加容易。但对大项目的开发或者框架设计，用设计模式来组织代码显然更好。
单例模式的探究
单例模式可以说只要是一个合格的开发都会写，但是如果要深究，小小的单例模式可以牵扯到很多东西，比如 多线程是否安全，是否懒加载，性能等等。还有你知道几种单例模式的写法呢？如何防止反射破坏单例模式？今天，我们来探究单例模式。
关于单例模式的概念，在这里就不在阐述了，相信每个小伙伴都了如指掌。我们直接进入正题：
2.1、饿汉式
public class Hungry {
private Hungry() {
}
private final static Hungry hungry = new Hungry();
public static Hungry getInstance() {
return hungry;
}
}
饿汉式是最简单的单例模式的写法，保证了线程的安全，在很长的时间里，我都是饿汉模式来完成单例的，因为够简单，后来才知道饿汉式会有一点小问题，看下面的代码：
public class Hungry {
private byte[] data1 = new byte[1024];
private byte[] data2 = new byte[1024];
private byte[] data3 = new byte[1024];
private byte[] data4 = new byte[1024];
private Hungry() {
}
private final static Hungry hungry = new Hungry();
public static Hungry getInstance() {
return hungry;
}
}
在Hungry类中，我定义了四个byte数组，当代码一运行，这四个数组就被初始化，并且放入内存了，如果长时间没有用到getInstance方法，不需要Hungry类的对象，这不是一种浪费吗？我希望的是 只有用到了 getInstance方法，才会去初始化单例类，才会加载单例类中的数据。所以就有了 第二种单例模式：懒汉式。
2.2、懒汉式
public class LazyMan {
private LazyMan() {
}
private static LazyMan lazyMan;
public static LazyMan getInstance() {
if (lazyMan == null) {
synchronized (LazyMan.class) {
if (lazyMan == null) {
lazyMan = new LazyMan();
}
}
}
return lazyMan;
}
}
DCL懒汉式的单例，保证了线程的安全性，又符合了懒加载，只有在用到的时候，才会去初始化，调用效率也比较高，但是这种写法在极端情况还是可能会有一定的问题。因为
lazyMan = new LazyMan();
不是原子性操作，至少会经过三个步骤：
-
分配内存
-
执行构造方法
-
指向地址
由于指令重排，导致A线程执行 lazyMan = new LazyMan();的时候，可能先执行了第三步（还没执行第二步），此时线程B又进来了，发现lazyMan已经不为空了，直接返回了lazyMan，并且后面使用了返回的lazyMan，由于线程A还没有执行第二步，导致此时lazyMan还不完整，可能会有一些意想不到的错误，所以就有了下面一种单例模式。
这种单例模式只是在上面DCL单例模式增加一个volatile关键字来避免指令重排：
public class LazyMan {
private LazyMan() {
}
private volatile static LazyMan lazyMan;
public static LazyMan getInstance() {
if (lazyMan == null) {
synchronized (LazyMan.class) {
if (lazyMan == null) {
lazyMan = new LazyMan();
}
}
}
return lazyMan;
}
}
2.3、静态内部类
还有这种方式是第一种饿汉式的改进版本，同样也是在类中定义static变量的对象，并且直接初始化，不过是移到了静态内部类中，十分巧妙。既保证了线程的安全性，同时又满足了懒加载。
public class Holder {
private Holder() {
}
public static Holder getInstance() {
return InnerClass.holder;
}
private static class InnerClass {
private static final Holder holder = new Holder();
}
}
2.4、万恶的反射
万恶的反射登场了，反射是一个比较霸道的东西，无视private修饰的构造方法，可以直接在外面newInstance，破坏我们辛辛苦苦写的单例模式。
public static void main(String[] args) {
try {
LazyMan lazyMan1 = LazyMan.getInstance();
Constructor declaredConstructor = LazyMan.class.getDeclaredConstructor(null);
declaredConstructor.setAccessible(true);
LazyMan lazyMan2 = declaredConstructor.newInstance();
System.out.println(lazyMan1.hashCode());
System.out.println(lazyMan2.hashCode());
System.out.println(lazyMan1 == lazyMan2);
} catch (Exception e) {
e.printStackTrace();
}
}
我们分别打印出lazyMan1，lazyMan2的hashcode，lazyMan1是否相等lazyMan2，结果显而易见，不相等；
那么，怎么解决这种问题呢？
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
在私有的构造函数中做一个判断，如果lazyMan不为空，说明lazyMan已经被创建过了，如果正常调用getInstance方法，是不会出现这种事情的，所以直接抛出异常！
但是这种写法还是有问题：
上面我们是先正常的调用了getInstance方法，创建了LazyMan对象，所以第二次用反射创建对象，私有构造函数里面的判断起作用了，反射破坏单例模式失败。但是如果破坏者干脆不先调用getInstance方法，一上来就直接用反射创建对象，我们的判断就不生效了：
public static void main(String[] args) {
try {
Constructor declaredConstructor = LazyMan.class.getDeclaredConstructor(null);
declaredConstructor.setAccessible(true);
LazyMan lazyMan1 = declaredConstructor.newInstance();
LazyMan lazyMan2 = declaredConstructor.newInstance();
System.out.println(lazyMan1.hashCode());
System.out.println(lazyMan2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
那么如何防止这种反射破坏呢？
public class LazyMan {
private static boolean flag = false;
private LazyMan() {
synchronized (LazyMan.class) {
if (flag == false) {
flag = true;
} else {
throw new RuntimeException("不要试图用反射破坏单例模式");
}
}
}
private volatile static LazyMan lazyMan;
public static LazyMan getInstance() {
if (lazyMan == null) {
synchronized (LazyMan.class) {
if (lazyMan == null) {
lazyMan = new LazyMan();
}
}
}
return lazyMan;
}
}
在这里，我定义了一个boolean变量flag，初始值是false，私有构造函数里面做了一个判断，如果flag=false，就把flag改为true，但是如果flag等于true，就说明有问题了，因为正常的调用是不会第二次跑到私有构造方法的，所以抛出异常。
看起来很美好，但是还是不能完全防止反射破坏单例模式，因为可以利用反射修改flag的值。
class Demo02{
public static void main(String[] args) {
try {
// 通过反射创建对象
Constructor declaredConstructor = LazyMan.class.getDeclaredConstructor(null);
Field field = LazyMan.class.getDeclaredField("flag");
field.setAccessible(true);
// 通过反射实例化对象
declaredConstructor.setAccessible(true);
LazyMan lazyMan1 = declaredConstructor.newInstance();
System.out.println(field.get(lazyMan1));
System.out.println(lazyMan1.hashCode());
//通过反射，修改字段的值！
field.set(lazyMan1,false);
LazyMan lazyMan2 = declaredConstructor.newInstance();
System.out.println(field.get(lazyMan2));
System.out.println(lazyMan2.hashCode());
} catch (Exception e) {
e.printStackTrace();
}
}
}
并没有一个很好的方案去避免反射破坏单例模式，所以轮到我们的枚举登场了。
2.5、枚举
枚举类型是Java 5中新增特性的一部分，它是一种特殊的数据类型，之所以特殊是因为它既是一种类(class)类型却又比类类型多了些特殊的约束，但是这些约束的存在也造就了枚举类型的简洁性、安全性以及便捷性。
public enum EnumSingleton {
INSTANCE;
public EnumSingleton getInstance(){
return INSTANCE;
}
}
class Demo04{
public static void main(String[] args) {
EnumSingleton singleton1=EnumSingleton.INSTANCE;
EnumSingleton singleton2=EnumSingleton.INSTANCE;
System.out.println("正常情况下，实例化两个实例是否相同："+(singleton1==singleton2));
}
}
枚举是目前最推荐的单例模式的写法，因为足够简单，不需要开发自己保证线程的安全，同时又可以有效的防止反射破坏我们的单例模式，我们可以看下newInstance的源码
重点就是红框中圈出来的部分，如果枚举去newInstance就直接抛出异常了。
反编译查看下枚举的源码
javap -p EnumSingleton.class
Compiled from "EnumSingleton.java"
public final class 单例模式.EnumSingleton extends java.lang.Enum<单例模式.EnumSingleton> {
public static final 单例模式.EnumSingleton INSTANCE;
private static final 单例模式.EnumSingleton[] $VALUES;
public static 单例模式.EnumSingleton[] values();
public static 单例模式.EnumSingleton valueOf(java.lang.String);
private 单例模式.EnumSingleton();
public 单例模式.EnumSingleton getInstance();
static {};
}
这个看的不清楚，我们可以下 jad 进行反编译，我们的素材中也都有！
jad -sjava EnumSingleton.class # 会生成一个java文件 Parsing EnumSingleton.class... Generating EnumSingleton.java
我们点开里面的源码
// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.kpdus.com/jad.html
// Decompiler options: packimports(3)
// Source File Name: EnumSingleton.java
package 53554F8B6A215F0F;
public final class EnumSingleton extends Enum
{
public static EnumSingleton[] values()
{
return (EnumSingleton[])$VALUES.clone();
}
public static EnumSingleton valueOf(String name)
{
return (EnumSingleton)Enum.valueOf(53554F8B6A215F0F/EnumSingleton, name);
}
private EnumSingleton(String s, int i)
{
super(s, i);
}
public EnumSingleton getInstance()
{
return INSTANCE;
}
public static final EnumSingleton INSTANCE;
private static final EnumSingleton $VALUES[];
static
{
INSTANCE = new EnumSingleton("INSTANCE", 0);
$VALUES = (new EnumSingleton[] {
INSTANCE
});
}
}
再次尝试破坏看一下！
package 单例模式;
import java.lang.reflect.Constructor;
public enum EnumSingleton {
INSTANCE;
public EnumSingleton getInstance(){
return INSTANCE;
}
}
class Demo04{
public static void main(String[] args) throws Exception {
EnumSingleton singleton1=EnumSingleton.INSTANCE;
EnumSingleton singleton2=EnumSingleton.INSTANCE;
System.out.println("正常情况下，实例化两个实例是否相同："+(singleton1==singleton2));
//Constructor constructor = EnumSingleton.class.getDeclaredConstructor(); //自身的类没有无参构造方法
Constructor constructor = EnumSingleton.class.getDeclaredConstructor(String.class,int.class);
constructor.setAccessible(true);
EnumSingleton enumSingleton = constructor.newInstance();
}
}
试图破坏，真的破坏不了！
假如有人问你单例模式，再也不用害怕了。
线程池底层工作原理
3.1、池化技术
程序的运行，其本质上，是对系统资源(CPU、内存、磁盘、网络等等)的使用。如何高效的使用这些资源是我们编程优化演进的一个方向。今天说的线程池就是一种对CPU利用的优化手段。
通过学习线程池原理，明白所有池化技术的基本设计思路。遇到其他相似问题可以解决。
池化技术
前面提到一个名词——池化技术，那么到底什么是池化技术呢 ?
池化技术简单点来说，就是提前保存大量的资源，以备不时之需。在机器资源有限的情况下，使用池化技术可以大大的提高资源的利用率，提升性能等。
在编程领域，比较典型的池化技术有：
线程池、连接池、内存池、对象池等。
主要来介绍一下其中比较简单的线程池的实现原理，希望读者们可以举一反三，通过对线程池的理解，学习并掌握所有编程中池化技术的底层原理。
我们通过创建一个线程对象，并且实现Runnable接口就可以实现一个简单的线程。可以利用上多核CPU。当一个任务结束，当前线程就接收。
但很多时候，我们不止会执行一个任务。如果每次都是如此的创建线程->执行任务->销毁线程，会造成很大的性能开销。
那能否一个线程创建后，执行完一个任务后，又去执行另一个任务，而不是销毁。这就是线程池。
这也就是池化技术的思想，通过预先创建好多个线程，放在池中，这样可以在需要使用线程的时候直接获取，避免多次重复创建、销毁带来的开销。
3.2、为什么使用线程池
例子：
10年前单核CPU电脑，假的多线程，像马戏团小丑玩多个球，CPU需要来回切换。
现在是多核电脑，多个线程各自跑在独立的CPU上，不用切换效率高。
线程池的优势
线程池做的工作主要是控制运行的线程数量，处理过程中将任务放入队列，然后在线程创建后启动这些任务，如果线程数量超过了最大数量，超出数量的线程排队等候，等待其他线程执行完毕，再从队列中取出任务来执行。
==它的主要特点：线程复用，控制最大并发数，管理线程！==
第一：降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗！
第二：提高响应速度。当任务到达时，任务可以不需要等待线程创建就能立即执行。
第三：提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。
3.3、线程池如何使用
Java中的线程池是通过Executor框架实现的，该框架中用到了Executor，Executors，ExecutorService，ThreadPoolExector这几个类。
转存失败重新上传取消
-
CachedThreadPool:可缓存的线程池，该线程池中没有核心线程，非核心线程的数量为Integer.max_value，就是无限大，当有需要时创建线程来执行任务，没有需要时回收线程，适用于耗时少，任务量大的情况。
-
SecudleThreadPool:周期性执行任务的线程池，按照某种特定的计划执行线程中的任务，有核心线程，但也有非核心线程，非核心线程的大小也为无限大。适用于执行周期性的任务。
-
SingleThreadPool:只有一条线程来执行任务，适用于有顺序的任务的应用场景。
-
FixedThreadPool:定长的线程池，有核心线程，核心线程的即为最大的线程数量，没有非核心线程
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class MyThreadPoolDemo {
public static void main(String[] args) {
//创建一个大小为5的线程池！
//ExecutorService threadPool = Executors.newFixedThreadPool(5);
//ExecutorService threadPool = Executors.newSingleThreadExecutor();
ExecutorService threadPool = Executors.newCachedThreadPool();
try {
for (int i = 1; i <= 10; i++) {
threadPool.execute(()->{
System.out.println(Thread.currentThread().getName()+"班里业务");
});
}
}catch (Exception e){
e.printStackTrace();
}finally {
threadPool.shutdown();
}
}
}
【查看这三个方法的源码，都是调用的同一个方法】
3.4、线程池几个重要的参数
//通过源码追踪，发现7大参数
public ThreadPoolExecutor(int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler) {
if (corePoolSize < 0 ||
maximumPoolSize <= 0 ||
maximumPoolSize < corePoolSize ||
keepAliveTime < 0)
throw new IllegalArgumentException();
if (workQueue == null || threadFactory == null || handler == null)
throw new NullPointerException();
this.acc = System.getSecurityManager() == null ?
null :
AccessController.getContext();
this.corePoolSize = corePoolSize;
this.maximumPoolSize = maximumPoolSize;
this.workQueue = workQueue;
this.keepAliveTime = unit.toNanos(keepAliveTime);
this.threadFactory = threadFactory;
this.handler = handler;
}
七大参数说明：
-
corePoolSize：线程池中的常驻核心线程数
-
maximumPoolSize：线程池中能够容纳同时执行的最大线程数，此值必须大于等于1
-
keepAliveTime：多余的空闲线程的存活时间，当前池中线程数量超过corePoolSize时，当空闲时间达到keepAliveTime时，多余线程会被销毁直到只剩下 corePoolSize 个线程为止
-
unit：keepAliveTime的单位
-
workQueue：任务队列，被提交但尚未被执行的任务
-
threadFactory：表示生成线程池中工作线程的线程工厂，用于创建线程，一般默认的即可！
-
handler：拒绝策略，表示当队列满了，并且工作线程大于等于线程池的最大线程数（maximumPoolSize）时如何来拒绝请求执行的runnable的策略。
1、第一个参数：int corePoolSIze， 核心池大小（其实这个就相当于是球队的主力队员，一般情况先都是这几个主力队员上场，但是如果遇到主力队员人数不够或者受伤之后不足以满足比赛才会启用maximumPoolSize这个参数），也就是线程池中会维持不被释放的线程数量。我们可以看到FixedThreadPool中这个参数值就是设定的线程数量，而SingleThreadExcutor中就是1，newCachedThreadPool中就是0，不会维持，只会缓存60L。但需要注意的是，在线程池刚创建时，里面并没有建好的线程，只有当有任务来的时候才会创建（除非调用方法prestartAllCoreThreads()与prestartCoreThread()方法），在corePoolSize数量范围的线程在完成任务后不会被回收。 2、第二个参数：int maximumPoolSize （可以把这个参数当成是球队后背球员，当主力不足时才会让后备队员上场救急）线程池的最大线程数，代表着线程池中能创建多少线程池。超出corePoolSize，小于maximumPoolSize的线程会在执行任务结束后被释放。此配置在CatchedThreadPool中有效。 3、第三个参数：long keepAliveTime ，刚刚说到的会被释放的线程缓存的时间。我们可以看到，正如我们所说的，在CachedThreadPool()构造过程中，会被设置缓存时间为60s（时间单位由第四个参数控制）。 4、第四个参数：TimeUnit unit ，设置第三个参数keepAliveTime的时间单位。
5、第五个参数：（就是四种阻塞的队列，也就是当线程池满了之后，再进来的任务都会放到这个阻塞队列中等待） 存储等待执行任务的阻塞队列，有多种选择，分别介绍：
SynchronousQueue——直接提交策略，适用于CachedThreadPool。它将任务直接提交给线程而不保持它们。如果不存在可用于立即运行任务的线程，则试图把任务加入队列将失败，因此会构造一个新的线程。此策略可以避免在处理可能具有内部依赖性的请求集时出现锁。直接提交通常要求最大的 maximumPoolSize 以避免拒绝新提交的任务（正如CachedThreadPool这个参数的值为Integer.MAX_VALUE）。当任务以超过队列所能处理的量、连续到达时，此策略允许线程具有增长的可能性。吞吐量较高。
LinkedBlockingQueue——无界队列，适用于FixedThreadPool与SingleThreadExcutor。基于链表的阻塞队列，创建的线程数不会超过corePoolSizes（maximumPoolSize值与其一致），当线程正忙时，任务进入队列等待。按照FIFO原则对元素进行排序，吞吐量高于ArrayBlockingQueue。
ArrayListBlockingQueue——有界队列，有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度地降低 CPU 使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞（例如，如果它们是 I/O边界），则系统可能为超过您许可的更多线程安排时间。使用小型队列通常要求较大的池大小，CPU使用率较高，但是可能遇到不可接受的调度开销，这样也会降低吞吐量。
6、第六个参数：RejectedExecutionHandler handler 这个参数是当任务到队列中之后缓存中队列阻塞的也已经满了的时候，会去启动备用后备队员去进行补充球队，但是如果此时后备队员也不够的话（），这个参数就会起到他的作用，会启用无法执行任务的策略：
ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。 ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。 ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程） ThreadPoolExecutor.CallerRunsPolicy：由调用线程处理该任务
7、第七个参数：threadFactory 这个参数就是一个线程工厂，主要的功能就是用来创建线程的
3.5、线程池底层工作原理
3.6、线程池用哪个？生成中如何设置合理参数
package 线程池底层工作原理;
import java.util.concurrent.*;
public class MyThreadPoolDemo {
public static void main(String[] args) {
//创建一个大小为5的线程池！
//ExecutorService threadPool = Executors.newFixedThreadPool(5);
//ExecutorService threadPool = Executors.newSingleThreadExecutor();
//ExecutorService threadPool = Executors.newCachedThreadPool();
ExecutorService threadPool = new ThreadPoolExecutor(
2,
5,
2L,
TimeUnit.SECONDS,
new LinkedBlockingDeque<>(3),
Executors.defaultThreadFactory(),
new ThreadPoolExecutor.AbortPolicy()
);
try {
for (int i = 1; i <= 10; i++) {
threadPool.execute(()->{
System.out.println(Thread.currentThread().getName()+"班里业务");
});
}
}catch (Exception e){
e.printStackTrace();
}finally {
threadPool.shutdown();
}
}
}
我们可以修改对应的参数，实现调优！和不报错！
使用代码查看CPU逻辑处理器
Runtime.getRuntime().availableProcessors();
面试题
线程池的拒绝策略你谈谈：
是什么：等待队列满了，线程池中的max线程也达到了，这时候我们就需要拒绝策略机制合理的处理这个问题。
JDK自带的拒绝策略：
AbortPolicy（默认）：直接抛出RejectedExecutionException异常组织系统正常运行 CallerRunsPolicy：即不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，从而降低新任务流量 DiscardOldestPolicy：抛弃队列中等待最久的任务，然后把当前任务加入队列中尝试再次提交当前任务 DiscardPolicy：直接丢弃任务，不予任何处理也不抛出异常。如果允许任务丢失，这是最好的一种方案
你在工作中 单一的 / 固定数的 / 可变的 三种创建线程池的方法，你用哪个多？
我们生产中只能使用自定义的。 线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式 说明： Executors 返回的线程池对象的弊端如下： 1） FixedThreadPool 和 SingleThreadPool : 允许的请求队列长度为 Integer.MAX_VALUE ，可能会堆积大量的请求，从而导致 OOM 。 2） CachedThreadPool 和 ScheduledThreadPool : 允许的创建线程数量为 Integer.MAX_VALUE ，可能会创建大量的线程，从而导致 OOM 。
合理配置线程池你是如何考虑的？
maximumPoolSize
我们可以把任务分为计算密集型和IO密集型。
计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。
计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。
第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。
IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。
总之，计算密集型程序适合C语言多线程，I/O密集型适合脚本语言开发的多线程。
==一般的公式是 CPU密集型：CPU核数 + 1，I/O密集型：CPU核数 / 1-阻塞系数（0.8~0.9）==
最后的最后，我们还是需要通过压力测试来进行微调，只有经过压测测试的检验，我们才能最终保证的配置大小是准确的。
Stream流式计算
1、流（Stream）到底是什么呢？
是数据渠道，用于操作数据源（集合、数组等）所生成的元素序列。
“集合讲的是数据，流讲的是计算！”
特点：
-
Stream 自己不会存储元素。
-
Stream 不会改变源对象，相反，他们会返回一个持有结果的新Stream。
-
Stream 操作是延迟执行的。这意味着他们会等到需要结果的时候才执行。
2、怎么使用呢？
-
创建一个Stream：一个数据源（数组，集合）
-
中间操作：一个中间操作，处理数据源数据
-
终止操作：一个终止操作，执行中间操作链，产生结果
3、代码验证
User实体类
Stream算法题
import java.util.Arrays;
import java.util.List;
/*
* 题目：请按照给出数据，找出同时满足以下条件的用户
* 也即以下条件：
* 1、全部满足偶数ID
* 2、年龄大于24
* 3、用户名转为大写
* 4、用户名字母倒排序
* 5、只输出一个用户名字 limit
**/
public class StreamDemo {
public static void main(String[] args) {
User u1 = new User(11, "a", 23);
User u2 = new User(12, "b", 24);
User u3 = new User(13, "c", 22);
User u4 = new User(14, "d", 28);
User u5 = new User(16, "e", 26);
List list = Arrays.asList(u1, u2, u3, u4, u5);
/*
* 1. 首先我们需要将 list 转化为stream流
* 2. 然后将用户过滤出来，这里用到一个函数式接口Predicate，我们可以使用lambda表达式简化
* 3. 这里面传递的参数，就是Stream流的泛型类型，也就是User，所以，这里可以直接返回用户id为偶数的用户信息;
* 4. 通过forEach进行遍历，直接简化输出 System.out::println ，等价于 System.out.println(u);
**/
//list.stream().filter(u -> {return u.getId()%2==0;}).forEach(System.out::println);
//list.stream().filter(u -> {return u.getId()%2==0;}).filter(u -> {return u.getAge()>24;}).forEach(System.out::println);;
//sorted() 自然排序，正排序 D->E
list.stream()
.filter(u -> {return u.getId()%2==0;})
.filter(u -> {return u.getAge()>24;})
.map(u -> {return u.getUserName().toUpperCase();})
.sorted((o1,o2)->{return o2.compareTo(o1);})
.limit(1)
.forEach(System.out::println);
/*
map解释
List list2 = Arrays.asList(1,2,3);
list2 = list2.stream().map(x -> {return x*2;}).collect(Collectors.toList());
for (Integer element : list2) {
System.out.println(element);
}
*/
}
}
ForkJoin
1、什么是ForkJoin
从JDK1.7开始，Java提供Fork/Join框架用于并行执行任务，它的思想就是讲一个大任务分割成若干小任务，最终汇总每个小任务的结果得到这个大任务的结果。
这种思想和HDFS--MapReduce很像（input --> split --> map --> reduce --> output）
主要有两步：
-
第一、任务切分；
-
第二、结果合并
它的模型大致是这样的：线程池中的每个线程都有自己的工作队列（PS：这一点和ThreadPoolExecutor不同，ThreadPoolExecutor是所有线程公用一个工作队列，所有线程都从这个工作队列中取任务），当自己队列中的任务都完成以后，会从其它线程的工作队列中偷一个任务执行，这样可以充分利用资源。
2、工作窃取
工作窃取（work-stealing）算法是指某个线程从其他队列里窃取任务来执行。工作窃取的运行流程图如下：
那么为什么需要使用工作窃取算法呢？
假如我们需要做一个比较大的任务，我们可以把这个任务分割为若干互不依赖的子任务，为了减少线程间的竞争，于是把这些子任务分别放到不同的队列里，并为每个队列创建一个单独的线程来执行队列里的任务，线程和队列一一对应，比如A线程负责处理A队列里的任务。但是有的线程会先把自己队列里的任务干完，而其他线程对应的队列里还有任务等待处理。干完活的线程与其等着，不如去帮其他线程干活，于是它就去其他线程的队列里窃取一个任务来执行。而在这时它们会访问同一个队列，所以为了减少窃取任务线程和被窃取任务线程之间的竞争，通常会使用双端队列，被窃取任务线程永远从双端队列的头部拿任务执行，而窃取任务的线程永远从双端队列的尾部拿任务执行。
工作窃取算法的优点是充分利用线程进行并行计算，并减少了线程间的竞争，其缺点是在某些情况下还是存在竞争，比如双端队列里只有一个任务时。并且消耗了更多的系统资源，比如创建多个线程和多个双端队列。
ForkJoinPool与其它的ExecutorService区别主要在于它使用“工作窃取”。
3、核心类
ForkJoinPool
WorkQueue是一个ForkJoinPool中的内部类，它是线程池中线程的工作队列的一个封装，支持任务窃取。
什么叫线程的任务窃取呢？就是说你和你的一个伙伴一起吃水果，你的那份吃完了，他那份没吃完，那你就偷偷的拿了他的一些水果吃了。存在执行2个任务的子线程，这里要讲成存在A,B两个个WorkQueue在执行任务，A的任务执行完了，B的任务没执行完，那么A的WorkQueue就从B的WorkQueue的ForkJoinTask数组中拿走了一部分尾部的任务来执行，可以合理的提高运行和计算效率。
每个线程都有一个WorkQueue，而WorkQueue中有执行任务的线程（ForkJoinWorkerThread owner），还有这个线程需要处理的任务（ForkJoinTask[] array）。那么这个新提交的任务就是加到array中。
ForkJoinTask
ForkJoinTask代表运行在ForkJoinPool中的任务。
主要方法：
-
fork() 在当前线程运行的线程池中安排一个异步执行。简单的理解就是再创建一个子任务。
-
join() 当任务完成的时候返回计算结果。
-
invoke() 开始执行任务，如果必要，等待计算完成。
子类：
-
RecursiveAction 一个递归无结果的ForkJoinTask（没有返回值）
-
RecursiveTask 一个递归有结果的ForkJoinTask（有返回值）
4、代码验证
核心代码
package FORKJOIN; import java.util.concurrent.RecursiveTask; public class ForkJoinWork extends RecursiveTask{ private Long start;//起始值 private Long end;//结束值 public static final Long critical = 10000L;//临界值 public ForkJoinWork(Long start, Long end) { this.start = start; this.end = end; } @Override protected Long compute() { //判断是否是拆分完毕 Long lenth = end - start; if(lenth<=critical){ //如果拆分完毕就相加 Long sum = 0L; for (Long i = start;i<=end;i++){ sum += i; } return sum; }else { //没有拆分完毕就开始拆分 Long middle = (end + start)/2;//计算的两个值的中间值 ForkJoinWork right = new ForkJoinWork(start,middle); right.fork();//拆分，并压入线程队列 ForkJoinWork left = new ForkJoinWork(middle+1,end); left.fork();//拆分，并压入线程队列 //合并 return right.join() + left.join(); } } }
三种测试
package FORKJOIN;
import java.util.concurrent.ForkJoinPool;
import java.util.concurrent.ForkJoinTask;
import java.util.stream.LongStream;
public class ForkJoinWorkDemo {
public static void main(String[] args) {
test3();
}
public static void test() {
//ForkJoin实现
long l = System.currentTimeMillis();
ForkJoinPool forkJoinPool = new ForkJoinPool();//实现ForkJoin 就必须有ForkJoinPool的支持
ForkJoinTask task = new ForkJoinWork(0L,1000000000L);//参数为起始值与结束值
Long invoke = forkJoinPool.invoke(task);
long l1 = System.currentTimeMillis();
System.out.println("invoke = " + invoke+" time: " + (l1-l));
//invoke = -5340232216128654848 time: 76474
}
public static void test2(){
//普通线程实现
Long x = 0L;
Long y = 1000000000L;
long l = System.currentTimeMillis();
for (Long i = 0L; i <= y; i++) {
x+=i;
}
long l1 = System.currentTimeMillis();
System.out.println("invoke = " + x+" time: " + (l1-l));
//invoke = -5340232216128654848 time: 160939
}
public static void test3(){
//Java 8 并行流的实现
long l = System.currentTimeMillis();
long reduce = LongStream.rangeClosed(0, 1000000000L).parallel().reduce(0, Long::sum);
long l1 = System.currentTimeMillis();
System.out.println("invoke = " + reduce+" time: " + (l1-l));
//invoke = -5340232216128654848 time: 15531
}
}
打个比方，假设一个酒店有400个房间，一共有4名清洁工，每个工人每天可以打扫100个房间，这样，4个工人满负荷工作时，400个房间全部打扫完正好需要1天。
Fork/Join的工作模式就像这样：首先，工人甲被分配了400个房间的任务，他一看任务太多了自己一个人不行，所以先把400个房间拆成两个200，然后叫来乙，把其中一个200分给乙。
紧接着，甲和乙再发现200也是个大任务，于是甲继续把200分成两个100，并把其中一个100分给丙，类似的，乙会把其中一个100分给丁，这样，最终4个人每人分到100个房间，并发执行正好是1天。
异步回调
1、概述
Future设计的初衷：对将来某个时刻会发生的结果进行建模。
当我们需要调用一个函数方法时。如果这个函数执行很慢,那么我们就要进行等待。但有时候,我们可能并不急着要结果。
因此,我们可以让被调用者立即返回,让他在后台慢慢处理这个请求。对于调用者来说,则可以先处理一些其他任务,在真正需要数据的场合再去尝试获取需要的数据。
它建模了一种异步计算，返回一个执行运算结果的引用，当运算结束后，这个引用被返回给调用方。在Future中出发那些潜在耗时的操作把调用线程解放出来，让它能继续执行其他有价值的工作，不再需要等待耗时的操作完成。
Future的优点：比更底层的Thread更易用。要使用Future，通常只需要将耗时的操作封装在一个Callable对象中，再将它提交给ExecutorService。
为了让程序更加高效，让CPU最大效率的工作，我们会采用异步编程。首先想到的是开启一个新的线程去做某项工作。再进一步，为了让新线程可以返回一个值，告诉主线程事情做完了，于是乎Future粉墨登场。然而Future提供的方式是主线程主动问询新线程，要是有个回调函数就爽了。所以，为了满足Future的某些遗憾，强大的CompletableFuture随着Java8一起来了
2、实例
import java.util.concurrent.CompletableFuture;
public class CompletableFutureDemo {
public static void main(String[] args) throws Exception {
//没有返回值的 runAsync 异步调用
CompletableFuture completableFuture = CompletableFuture.runAsync(() -> {
System.out.println(Thread.currentThread().getName() + "没有返回，update mysql ok");
});
completableFuture.get();
//有返回值的 供给型参数接口
CompletableFuture completableFuture2 = CompletableFuture.supplyAsync(() -> {
System.out.println(Thread.currentThread().getName() + "completableFuture2");
int i = 10/0;
return 1024;
});
System.out.println(completableFuture2.whenComplete((t, u) -> { //编译完成，正常结束输出
System.out.println("===t:" + t); //正常结果
System.out.println("===u:" + u); //信息
}).exceptionally(e -> { //结果异常，非正常结束
System.out.println("=======exception:" + e.getMessage());
return 555;
}).get());
}
}
Java内存模型JMM
1、什么是JMM(面试高频) JVM
JMM即为JAVA 内存模型（java memory model）。因为在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，但是换了个系统就出现各种问题。Java内存模型，就是为了屏蔽系统和硬件的差异，让一套代码在不同平台下能到达相同的访问结果。JMM从java 5开始的JSR-133发布后，已经成熟和完善起来。
JMM规定了内存主要划分为主内存和工作内存两种。此处的主内存和工作内存跟JVM内存划分（堆、栈、方法区）是在不同的层次上进行的，==如果非要对应起来，主内存对应的是Java堆中的对象实例部分，工作内存对应的是栈中的部分区域，从更底层的来说，主内存对应的是硬件的物理内存，工作内存对应的是寄存器和高速缓存。
JVM在设计时候考虑到，如果JAVA线程每次读取和写入变量都直接操作主内存，对性能影响比较大，所以每条线程拥有各自的工作内存，工作内存中的变量是主内存中的一份拷贝，线程对变量的读取和写入，直接在工作内存中操作，而不能直接去操作主内存中的变量。但是这样就会出现一个问题，当一个线程修改了自己工作内存中变量，对其他线程是不可见的，会导致线程不安全的问题。因为JMM制定了一套标准来保证开发者在编写多线程程序的时候，能够控制什么时候内存会被同步给其他线程。
操作的数据要写会主存！
内存交互操作
内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许例外）
-
lock （锁定）：作用于主内存的变量，把一个变量标识为线程独占状态
-
unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
-
read （读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
-
load （载入）：作用于工作内存的变量，它把read操作从主存中变量放入工作内存中
-
use （使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机遇到一个需要使用到变量的值，就会使用到这个指令
-
assign （赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变量副本中
-
store （存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，以便后续的write使用
-
write （写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中
JMM对这八种指令的使用，制定了如下规则：
-
-
不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
-
不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
-
不允许一个线程将没有assign的数据从工作内存同步回主内存
-
一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前，必须经过assign和load操作
-
一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
-
如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
-
如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
-
对一个变量进行unlock操作之前，必须把此变量同步回主内存
-
JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，使用java的happen-before规则来进行分析。
2、JMM的内存模型
线程A感知不到线程B操作了值的变化！如何能够保证线程间可以同步感知这个问题呢？只需要使用Volatile关键字即可！volatile 保证线程间变量的可见性，简单地说就是当线程A对变量X进行了修改后，在线程A后面执行的其他线程能看到变量X的变动，更详细地说是要符合以下两个规则 ：
-
线程对变量进行修改之后，要立刻回写到主内存。
-
线程对变量读取的时候，要从主内存中读，而不是缓存。
各线程的工作内存间彼此独立，互不可见，在线程启动的时候，虚拟机为每个内存分配一块工作内存，不仅包含了线程内部定义的局部变量，也包含了线程所需要使用的共享变量（非线程内构造的对象）的副本，即，为了提高执行效率。 volatile是不错的机制，但是也不能保证原子性。
3、代码验证
package JMM;
//Volatile 用来保证数据的同步，也就是可见性
public class JMMVolatileDemo01 {
// 不加 volatile 就会死循环，这里给大家将主要是为了面试，可以避免指令重排
private volatile static int num = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(()->{
while (num==0){ //此处不要编写代码,让计算机忙的不可开交
}
}).start();
Thread.sleep(1000);
num = 1;
}
}