线程数

文章目录 个人感受 个人解毒（du） 基础篇 (6讲) 01高并发系统：它的通用设计方法是什么？ 02 | 架构分层：我们为什么一定要这么做？ 03 | 系统设计目标（一）：如何提升系统性能？ 04 | 系统设计目标（二）：系统怎样做到高可用？ 05 | 系统设计目标（三）：如何让系统易于扩展？ 07 | 池化技术：如何减少频繁创建数据库连接的性能损耗？ 08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？ 09 | 数据库优化方案（二）：写入数据量增加时，如何实现分库分表？ 10 | 发号器：如何保证分库分表后ID的全局唯一性？ 11 | NoSQL：在高并发场景下，数据库和NoSQL如何做到互补？ 演进篇 · 缓存篇 (6讲) 12 | 缓存：数据库成为瓶颈后，动态数据的查询要如何加速？ 13 | 缓存的使用姿势（一）：如何选择缓存的读写策略？ 14 | 缓存的使用姿势（二）：缓存如何做到高可用？ 15 | 缓存的使用姿势（三）：缓存穿透了怎么办？ 16 | CDN：静态资源如何加速？ 加餐 | 数据的迁移应该如何做？ 演进篇 · 消息队列篇 (6讲) 17 | 消息队列：秒杀时如何处理每秒上万次的下单请求？ 18 | 消息投递：如何保证消息仅仅被消费一次？ 19 | 消息队列：如何降低消息队列系统中消息的延迟？ 演进篇 · 分布式服务篇 (9讲) 21 |

一、前言 本来写了脚本用于暴力破解密码，可是1秒钟尝试一个密码2220000个密码我的天，想用多线程可是只会一个for全开，难道开2220000个线程吗？只好学习控制线程数了，官方文档不好看，觉得结构不够清晰，网上找很多文章也都不很清晰，只有for全开线程，没有控制线程数的具体说明，最终终于根据多篇文章和官方文档算是搞明白基础的多线程怎么实现法了，怕长时间不用又忘记，找着麻烦就贴这了，跟我一样新手也可以参照参照。 先说进程和线程的区别： 地址空间:进程内的一个执行单元;进程至少有一个线程;它们共享进程的地址空间;而进程有自己独立的地址空间; 资源拥有:进程是资源分配和拥有的单位,同一个进程内的线程共享进程的资源 线程是处理器调度的基本单位,但进程不是. 二者均可并发执行. 不能理解的话简单打比方就是一个进程就像一个程序一样，并发互不干扰。一个进程靠一个或多个线程执行处理，并发的线程是cpu在不停的来回切换执行，当然是快到你感觉不出的。 拿上面我遇到的困难来说吧，大量的数据需要执行相同的处理，一个操作中间可能会有一些等待时间，一个一个执行浪费大量时间，那么就同时执行吧，我们可以用两种并行办法： 进程并行或者线程并行 各有优缺点，要看情况，不是绝对的，在此不讨论这个，这引出下面两种Python并行处理方法（注释感觉很清晰详细了，不再多说） 二、进程处理方法 #coding:utf-8

很早之前就看过线程池源码（知道大概的运行原理），但是只是知道怎么用，并没有深究。这次为了帮助自己深入理解线程池，决定手动写一个极简（陋）的线程池，顺便记录思考和造轮过程。 虽然不太可能和jdk自带的那么完美，但是该有的功能还是要有： - 新建线程池，有核心线程数和最大线程数，线程存活时间，队列 - 在线程池加入线程，当前线程数不超过核心线程数就新建线程，超过核心放队列，队列满了再新建线程，达到最大线程 - 全部线程运行完成后会保留核心线程数，支持线程存活时间 - 立即关闭线程池 - 优雅的关闭线程池 1.新建一个轮子线程池类,就一个构造函数，把需要的参数都传进来 2.用ThreadPoolExecutor的时候，新建了线程池就会往里面提交线程了，我们写的也一样，而且往线程池里面加线程的时候就会判断：当前运行线程数是否大于核心线程数，是否大于最大线程数等，这里需要一个当前运行线程数的变量。 所以这里增加一个成员变量activeCount，初始值为0，运行一个线程就加1，线程运行结束就减1，这里面减的时候是在不同线程里面，所以为了线程安全用AtomicInteger类型 /** 当前活动线程数 */ private AtomicInteger activeCount = new AtomicInteger(0); 提交线程的方法，看过ThreadPoolExecutor源码的应该知道

线程池原理 以ThreadPoolExecutor为例 private static final ThreadPoolExecutor EXECUTOR_SERVICE = new ThreadPoolExecutor(100,120,60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(1000), new ThreadFactoryBuilder().setNameFormat("thread-pool-%d").build(), new ThreadPoolExecutor.CallerRunsPolicy()); 参数说明 为什么要使用线程池 使用线程池主要有以下好处: 降低资源消耗。通过复用已存在的线程和降低线程关闭的次数尽可能降低系统性能损耗 提升系统响应速度。通过复用线程，省去创建线程的过程，因此整体上提升了系统的响应速度 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，因此，需使用线程池来管理线程。 实现原理 线程池内部常量 //ct1的低29位表示线程池中的线程数，高3为表示当前线程状态 private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); private static final int

案发现场 昨天晚上突然短信收到 APM （即 Application Performance Management 的简称，我们内部自己搭建了这样一套系统来对应用的性能、可靠性进行线上的监控和预警的一种机制）大量告警 （画外音: 监控是一种非常重要的发现问题的手段，没有的话一定要及时建立哦） 紧接着运维打来电话告知线上部署的四台机器全部 OOM (out of memory, 内存不足)，服务全部不可用,赶紧查看问题! 问题排查 首先运维先重启了机器，保证线上服务可用，然后再仔细地看了下线上的日志，确实是因为 OOM 导致服务不可用 第一时间想到 dump 当时的内存状态，但由于为了让线上尽快恢复服务，运维重启了机器，导致无法 dump 出事发时的内存。所以我又看了下我们 APM 中对 JVM 的监控图表 画外音： 一种方式不行，尝试另外的角度切入！再次强调，监控非常重要！完善的监控能还原当时的事发现场，方便定位问题。 不看不知道，一看吓一跳，从 16：00 开始应用中创建的线程居然每时每刻都在上升，一直到 3w 左右，重启后（蓝色箭头），线程也一直在不断增长），正常情况下的线程数是多少呢，600！问题找到了，应该是在下午 16:00 左右发了一段有问题的代码，导致线程一直在创建，且创建的线程一直未消亡!查看发布记录,发现发布记录只有这么一段可疑的代码 diff：在

线程池的线程数配置，主要看服务器是属于以下哪种类型： （1）CPU密集型。 （2）IO密集型。 一：CPU密集型算法： （1）名称解释：CPU密集型的意思是该任务需要大量的运算，而没有阻塞，CPU一直全速运行。CPU密集任务只有在真正多核CPU上才可能得到加速（通过多线程），而在单核CPU上，无论你开几个模拟的多线程该任务都不可能得到加速，因为CPU总的运算能力就那些。 （2）计算方法：CPU密集型任务配置尽可能少线程数量。公式=CPU核数+1个线程的线程池。如我的CPU是16核，16+1=17。那么我们就配置17个线程池。 二：IO密集型算法一共分两种： （1）名称解释：IO密集型，即该任务需要大量的IO，即大量的阻塞，在单线程上运行IO密集型的任务会导致浪费大量的CPU运行能力浪费在等待。所以在Io密集型任务中使用多线程可以大大的加速程序运行，即使在单核CPU上，这种主要就是利用了被浪费掉的阻塞时间。IO密集型时，大部分线程都阻塞，故需要多配置线程数。 （2）算法一：由于IO密集型任务线程并不是一直在执行任务，则应配置尽可能多的线程。算法：CPU核数 * 2。如我的CPU核数是16核，16*2=32。 （3）算法二：CPU核数 / 1 - 阻塞系数。阻塞系数在 0.8 - 0.9 之间。如我的CPU核数是16核，16/1-0.9=160。 备注：System.out

案发现场 昨天晚上突然短信收到 APM （即 Application Performance Management 的简称），我们内部自己搭建了这样一套系统来对应用的性能、可靠性进行线上的监控和预警的一种机制）大量告警 画外音: 监控是一种非常重要的发现问题的手段，没有的话一定要及时建立哦 紧接着运维打来电话告知线上部署的四台机器全部 OOM (out of memory, 内存不足)，服务全部不可用,赶紧查看问题! 问题排查 首先运维先重启了机器，保证线上服务可用，然后再仔细地看了下线上的日志，确实是因为 OOM 导致服务不可用 第一时间想到 dump 当时的内存状态，但由于为了让线上尽快恢复服务，运维重启了机器，导致无法 dump 出事发时的内存。所以我又看了下我们 APM 中对 JVM 的监控图表 画外音： 一种方式不行，尝试另外的角度切入！再次强调，监控非常重要！完善的监控能还原当时的事发现场，方便定位问题。 不看不知道，一看吓一跳，从 16：00 开始应用中创建的线程居然每时每刻都在上升，一直到 3w 左右，重启后（蓝色箭头），线程也一直在不断增长），正常情况下的线程数是多少呢，600！问题找到了，应该是在下午 16:00 左右发了一段有问题的代码，导致线程一直在创建，且创建的线程一直未消亡!查看发布记录,发现发布记录只有这么一段可疑的代码 diff：在

package cn.ce.ebiz.manager.searchEngine; import java.util.ArrayList; import java.util.List; import java.util.concurrent.*; /** * @description 线程池工具类 * @author dengyinghui * @date 2019/11/26 20:09 * @version 1.0.0.1 */ public class ThreadPool { private static ThreadPoolExecutor executorService; /** * 核心线程数 * Runtime.getRuntime().availableProcessors()返回虚拟机的最大可用的处理器数量;决不会小于一个 * 处理的任务: * IO密集型任务(数据库数据交互、文件上传下载、网络数据传输等等)CORE_POOL_SIZE 取 2 * Runtime.getRuntime().availableProcessors() * 计算密集型任务(复杂算法)CORE_POOL_SIZE 取 Runtime.getRuntime().availableProcessors() */ private static int CORE_POOL_SIZE = 20

实例说明 　　本实例介绍如何优化Tomcat服务器，如果用户并发量小，系统可能不会出问题，但是并发量大时，系统反应速度迅速下降，由于不了解原因，拼命地在自己应用中寻找问题，从而浪费了宝贵的时间。 设计过程 屏蔽DNS查询 Web应用程序可以通过Web容器提供的getRemoteHost()方法获得访问Web应用客户的IP地址和名称，但是这样会消耗Web容器的资源，并且还需要通过IP地址和DNS服务器反查用户的名字，因此当系统上线时，可以将这个属性关闭，从而减少资源消耗。那么Web容器也就只能记录下IP地址，修改的属性为enableLookups="false"。 调整线程数 Tomcat通过线程池来为用户访问提供相应，对于上线的系统初步估计用户并发数量之后，在调整线程池容量。例如，用户的并发数量在100左右时，可以设置minProcessors=“100”，maxProcessors=“100”。将最大和最小设置为一样的，线程池不会再释放空闲的线程，当用户访问突然增加时，不需要再消耗系统资源去创建新的线程。 调整最大连接数 这个其实最复杂，即使用户并发量大，但是系统反应速度快，也没必要把这个值设置太高，高了系统需要消耗大量的资源去切换线程，但是如果设置的太低也会造成应用无法满足用户并发需求。因此设置这个最好能够结合整个系统的跟踪和调优，使系统达到最好的平稳状态

案发现场 昨天晚上突然短信收到 APM （即 Application Performance Management 的简称），我们内部自己搭建了这样一套系统来对应用的性能、可靠性进行线上的监控和预警的一种机制）大量告警 画外音: 监控是一种非常重要的发现问题的手段，没有的话一定要及时建立哦 紧接着运维打来电话告知线上部署的四台机器全部 OOM (out of memory, 内存不足)，服务全部不可用,赶紧查看问题! 问题排查 首先运维先重启了机器，保证线上服务可用，然后再仔细地看了下线上的日志，确实是因为 OOM 导致服务不可用 第一时间想到 dump 当时的内存状态，但由于为了让线上尽快恢复服务，运维重启了机器，导致无法 dump 出事发时的内存。所以我又看了下我们 APM 中对 JVM 的监控图表 画外音： 一种方式不行，尝试另外的角度切入！再次强调，监控非常重要！完善的监控能还原当时的事发现场，方便定位问题。 不看不知道，一看吓一跳，从 16：00 开始应用中创建的线程居然每时每刻都在上升，一直到 3w 左右，重启后（蓝色箭头），线程也一直在不断增长），正常情况下的线程数是多少呢，600！问题找到了，应该是在下午 16:00 左右发了一段有问题的代码，导致线程一直在创建，且创建的线程一直未消亡!查看发布记录,发现发布记录只有这么一段可疑的代码 diff：在