阿里云的wordpress站点地址写错,四川建设网站项目招标,wordpress 账号 有效期,wordpress 升级ssl一、单例模式#xff08;是一种设计模式#xff09;
设计模式有很多种#xff0c;不同的语法中也有不同的设计模式
单例 单个实例#xff08;对象)
某个类#xff0c;在一个进程中#xff0c;只应该创建出一个实例#xff0c;#xff08;原则上不该有多个#xff…一、单例模式是一种设计模式
设计模式有很多种不同的语法中也有不同的设计模式
单例 单个实例对象)
某个类在一个进程中只应该创建出一个实例原则上不该有多个使用单例模式可以对咱们的代码进行个更严格的校验和检查
实现单例模式有多种实现方法有两种最基础的实现方式
1、饿汉模式
饿表示非常迫切因为实例在类加载的时候就创建了创建时机非常早程库一启动实例就创建了
2、懒汉模式
创建实例的时机不大一样创建实例的时机更晚只到第一次使用才会创建实例
首次调用getlnstane此时 instance 引用为 null就会进入 if 条件从而把实例创建出来后续再调用 getInstance 由于 instance 不再是null此时不会进入 if 直接返回之前创建好的引用
该操作的执行时机并不确定甚至可能整个程序压根用不到这些方法就把创建的操作省下来了
饿汉模式 getInstance 直接返回 Instance 实例该操作的本质就是读操作多个线程同时读是线程安全的
懒汉模式有读有写是线程不安全的
1、该线程安全问题本质上是读比较写这三个操作不是原子的导致后一个线程读的值前一个线程还没写(脏读)把锁加在外面才能保证读和修改是一个整体
2、代码每次 getInstance 都要加锁但加锁只是在 new 出对象前加上很必要对象new完以后后续调用getinstance是读操作不用加锁
可以给上述代码一个判定对象未创建才加锁创建了就不加锁了
3、指令重排序引起的线程问题指令重排序也是编译器优化的一种方式
调整原有代码的执行顺序保证逻辑不变的情况下提高程序的效率解决该问题核心思路还是volatile
二、阻塞队列基于普通队列做出的扩展先进先出线程安全的)
1、带有阻塞性质
若是对一个已经满了的队列进行入队列此时入队列就会阻塞一直到队列不满结束
若是对一个已空的队列进行出队列此时出队列就会阻塞一直到队列不空结束
2、基于阻塞队列就可以实现“生产者消费者模型”
引入生产者消费者模型是为了更好做到“解耦合“
实际开发中经常会涉及到分布式系统服务器的功能不是由一个服务器来完成的而是每个服务器负责一部分功能最后通过服务器之间的网络通信完成整个功能
3、阻塞队列代价需加机器引入更多的硬件资源
1、上述阻塞队列并非是简单的数据结构而是基于这个数据结构实现的服务器程序又被布署到单独的主机上了(被称为消息队列message queue)
2、整个系统的结构更复杂了要维护的服务器更多了
3、效率会降低引入中间商还是有差价的请求从A发送给B这个过程要经历队列的转发也是有一定开销的
4、削峰填谷
外界请求突发峰值突发的峰值就会使抗压能力更弱的服务器挂掉使用阻塞队列即使外面的请求出现峰值也是由队列来承受峰值请求队列无业务逻辑只是存储数据抗压能力是比较强的
当请求出现谷值队列也会照常提供给服务器请求让服务器保证正常运转
5、Java中提供了现成的阻塞队列数据结构
ArrayBlockingQueue 基于数组实现
LinkedBlackingQueue 基于链表实现
PriorityBlackingQueue 带优先级的队列
put 方法是带阻塞的加入offer 不带阻塞take方法出队列也是带阻塞的
对程序的优化归根结底增加机器、增加硬件资源是最立杆见影的做法仅仅是软件层面的优化投入产出比较低
实际开发中生产者消费者模型住往是多个生产者消费者这里的生产者和消费者不仅仅是一个线程也可能是一个独立的服务器程序其至是一组服务器程序
生产者消费者模型核心仍是阻塞队列使用synchronized 和 wait/notify来达到线程安全和阻塞
三、实现定时器
设定一个时间当时间到了的时候定时器自动去执行某个逻辑
什么样的情况能的使用lambda得是函数式接口(interface只能有这一个接口)
Timer里内置了线程(前台线程)timer 不知道代码是否会添加新的任务进来处于严阵以待的状态要使用 cncel 主动结束否则 timer 不知道是否其他地方要继续添加任务
定时器核心
1、有个扫描线程负责判定时间到/执行任务
2、还要有个数据结构保护所有被注册的任务
数据结构用优先级队列来表示在多线程下使用调用 schedule 是一个线程扫描是另一个线程要关注线程安全问题)
四、线程池
提前把要用的对象准备好用完的对象也不要立刻释放先留着下次备用
虽然线程成本低但是频繁的创建和销毁开销还是很大的
1、优化方案
1、引入轻量级线程也称为纤程/协程协程本质是程序员在用户代码中进行调度不是靠内核的调度器调度节省了很多调度上的开销
2、线程池
在使用过程中并未真的频繁创建销毁而只是从线程池里取线程使用完了还给线程池从线程池中取线程(纯用户代码可控)
通过系统申清来创建线程需要内核来完成(不太可控)
2、标准库中的线程池 ThreadPoolExecutor
这个类构造方法的参数侧面映射出线程池的设计思路需要咱们了解一下标准库提供的线程池持有的线程个数并非是一成不变的会根据当前任务量自适应线程数
int corePoolSize 核心线程数(线程池内最少有多少线程)
int maximumpoolSize 最大线程数(线程池内最多有多少线程)
kpepAliveTime 实习生线程空闲时间超过了这个时间阈值就会被销毁
BlockingQueueRunnabe 使用Runnable作为描述任务的主体若想任务带有优先级则使用PriorityBlrkingQueue
ThreadFactory 线程工厂(工厂模式也是常见的设计模式)
通过静态方法封装 new 操作在方法内部没定不同属性完成对象初始化构造对象的过程就是工厂模式
线程工厂提供了方法让方法封装 new Thread 操作并给 Thread 设置一些属性
3、RejectedExecutionHandler(拒绝策略)
线程池能容纳的元素是有限的若继续添加任务会怎么样
AborPolicy继续添加任务直接抛出异常新的任务未完成旧的任务也没法做了
calerRunsPolicy 新的任务由添加任务的线程执行
discardoldestPolicy丢弃最老的任务
discardPolicy丢弃最新任务(调用的线程不执行该任务线程池也不执行
创建线程池要没定线程池的线程数量若一个进程中所有的线程都是cpu密集型每个线程所有工作都是在cpu上执行的此时线程数不该超过N(cpu核心数)
若一个进程的所有线程都是IO密集型每个线程大部分工作都等待IOcpu消耗很少此时线程数可以很多远远超过N
综上由于程序的复杂性很难对于线程池的线程数进行估数可通过测试的方式尝试给线程池设定不同的线程数目分别进行能测试衡量每种程数目下总的时间开销和系统资源占用的开销找到二者的合适值
