设计模式(单例模式,工厂模式),线程池

目录

什么是设计模式?

单例模式

饿汉模式

懒汉模式

工厂模式

线程池

线程池种类

ThreadPoolExcutor的构造方法:

手动实现一个线程池 

---

什么是设计模式?

计算机行业程序员水平层次不齐,为了让所有人都能够写出规范的代码,于是就有了设计模式,针对一些典型的场景,给出一些典型的解决方案

单例模式

单例模式 ==> 单个实例(对象)

在一些场景中,有的特定类只能创建一个实例,不能创建多个实例
使用了单例模式后,此时就不能创建多个实例了,我们想创建多个实例都难,单例模式就是针对上述的需求场景进行了更强制的保证,通过巧用java的语法,达成某个类 只能被创建出一个实例这样的效果(当程序员不小心创建了多个实例,就会报错)

单例模式实现

饿汉模式

// 饿汉模式的 单例模式 实现
// 此处保证 Singleton 这个类只能创建出一个实例
class Singleton{// 在此处,先把实例给创建出来private static Singleton instance = new Singleton();// 如果需要使用 instance,通过统一的Singleton.getInstance() 方式获取public static Singleton getInstance(){return instance;}// 为了避免 Singleton 类不小心被复制多份// 把构造方法设为 private,在类外面,就无法通过new 的方式来创建这个 Singleton了private Singleton(){};
}
public class Thread3 {public static void main(String[] args) {Singleton s = Singleton.getInstance();Singleton s2 = Singleton.getInstance();System.out.println(s==s2);Singleton s3 = new Singleton(); // 报错,原因是Singleton的构造方法被private修饰,因此无法通过new的方式创建Singleton对象}
}

懒汉模式

class Singleton2{ private static volatile Singleton2 instance = null; //使用volatile表示instance是个易变的public static Singleton2 getInstance(){if (instance==null) {   // 此处负责判断是否要加锁synchronized (Singleton2.class) {if(instance==null){   // 此处判断是否要创建对象instance = new Singleton2();}}}return instance;}private Singleton2(){};
}

懒汉模式下,有创建Singleton对象的操作(写操作),所以可能会出现线程安全问题,因此我们要进行加锁操作,并标注instance是一个易变的对象(避免内存可见性问题,和指令重排序问题)

工厂模式

工厂模式: 使用普通的方法,来代替构造方法,创建对象.  在java中,构造方法存在一定缺陷,构造方法要求构造名必须为类名(方法名相同),构造参数可以不同,没用返回值.如果我们只构造一种对象可以忽略这个缺陷,如果构造多种不同的情况的对象可能会出现问题,比如想要实现俩个不同的构造方法,但是它们的参数类型恰好都相同,但表达的意义不同,这时java就无法区分了.为了解决这个问题,就可以使用工程模式

比如分别使用笛卡尔坐标系和极坐标系表示坐标

import java.awt.*;
class PointFactory{public static Point makePointByXY(double x,double y){}public static Point makePointByRA(double r,double a){}
}
public class Thread6 {public static void main(String[] args) {Point p = PointFactory.makePointByXY(10,20);Point p2 = PointFactory.makePointByRA(10,30);}
}

线程池

线程存在的意义: 使用进程实现并发编程,"太重了",引入线程(轻量级进程),创建线程比创建线程更高效,销毁线程比销毁进程更高效,调度线程比调度进程更高效,此时使用多线程就可以在很多时候代替进程实现并发编程了

线程池存在的意义: 当我们需要频繁创建销毁线程的时候,就发现开销也很大,想要进一步的提高效率,可以: 1.搞一个协程(轻量级线程) 2.使用线程池,事先把需要使用的线程创建好,放到池中,后面需要使用的时候,从池中获取,如果用完了,再还给池.(创建线程和销毁线程是交由操作系统内核去完成的,从池子里获取/还给池,是自己用户代码就能实现的,不必交给内核操作)

public class Thread5 {public static void main(String[] args) {// 此处就构造了一个 10 个线程的线程池,就可以随时安排这些线程干活了ExecutorService pool =  Executors.newFixedThreadPool(10);// 当前往线程池中放了1000个任务,这1000个任务由线程池中的10个线程去执行for (int i = 0;i < 1000;i++) {pool.submit(()->{System.out.println("hello");});}}
}

线程池提供了一个重要的方法,submit,可以给线程池提交若干个任务,这若干个任务可以由线程池中的线程去执行完成..线程池中创建的线程是前台线程,需要执行完成后,主线程才可以结束. 
这里1000个任务相当于在一个队列中,线程池中的这10个线程就依次取这个队列中的任务,取一个就执行一个,执行完成后,再在这个队列中取任务去执行 

线程池种类

这些线程池,本质上都是通过包装 ThreadPoolExecutor 来实现的 

ThreadPoolExcutor的构造方法:

corePoolSize : 核心线程数,

maximumPoolSize:  最大线程数,相当于线程池把线程分为俩大类,一类是核心线程,一类是非核心线程,最大线程数就是核心线程和非核心线程之和
一个程序有时任务多,有时任务少,如果任务多,我们就需要多一些线程,如果任务少,就需要线程尽量少,此时我们就可以保留核心线程,而淘汰掉一些非核心线程

实际开发中,线程池的线程数设定成多少合适?

程序分为CPU密集型,每个线程执行的任务都需要狂转CPU(进行一系列算术运算),此时线程池线程数最多不超过CPU核数,因为cpu密集型要一直占用cpu,创建更多的线程也没用
IO密集型,每个线程的工作就是等待IO(读写硬盘,读写网卡,等待用户输入),不占CPU,此时这样的线程处于阻塞状态,不参与CPU调度,这个时候创建多个线程,不再受制于CPU核数了
实践中确定线程数,通过实验的方式,康康设置几个线程合适

long keepAliveTime: 非核心线程数不工作的最大时间,如果超过这个时间就销毁

TimeUnit unit: 时间单位,ms,s,分钟,小时......

BlockingQueue<Runnable> workQueue: 线程池的任务队列

ThreadFactory threadFactory: 用于创建线程

RejectedExecutionHandler handler: 描述了线程池的"拒绝策略",是一个特殊的对象,描述了当线程池任务队列满了之后,如果继续添加任务,线程池会有什么样的行为,总共有以下4种策略
ThreadPoolExcutor.AbortPolicy: 如果任务队列满了,再新增任务,直接抛出异常
ThreadPoolExcutor.CallerRunsPoliy: 如果任务队列满了,多出来的任务,谁加的就由谁去执行(交给调用者去执行)
ThreadPoolExcutor.DisardOlderdestPolicy: 如果任务队列满了,就丢弃最老的任务
ThreadPoolExcutor.DiscardPolicy: 如果任务队列满了,就丢弃最新的任务

手动实现一个线程池 

一个线程池中至少有俩个部分,一个是阻塞队列,用来保存任务,一个是若干个工作线程

class MyThreadPool{private BlockingQueue<Runnable> queue = new LinkedBlockingQueue<>();// n 表示线程数量public MyThreadPool(int n){// 创建 n 个线程for (int i = 0; i < n; i++) {Thread t = new Thread(()->{while (true){try {Runnable runnable =  queue.take();runnable.run();} catch (InterruptedException e) {e.printStackTrace();}}});t.start();}}// 注册任务交给线程池public void submit(Runnable runnable) {try {queue.put(runnable);} catch (InterruptedException e) {e.printStackTrace();}}
}