沃峰科技助力企业客户服务升级，全面解决全国门店运维问题
06-18
1.本文知识脉络以Java为例。线程使用中遇到哪些痛点？引入了池化的思想，那么Java是如何使用线程池来解决此类问题的呢？ Java线程池使用中的问题。
公司是如何实践的？本文的亮点在于系统地讲解了Java中线程池是如何引入、实践、演变的过程。无论是在工作中还是在面试中，都可以帮助学生系统地解释线程池问题。
1.1.线程的痛点随着计算机多核CPU的演进，为了充分发挥线程并发性，开发者开始利用多线程来提高系统性能，充分发挥多核CPU带来的便利。每当我们需要执行任务时，我们都需要创建一个新的线程来运行。
我们知道的是，线程的创建和销毁都需要开销，无论是内存使用还是CPU使用。无限创建线程的最终结果是耗尽内存和CPU，导致系统无法接收新的请求，从而系统不可用。
这是我们不愿意看到的灾难。那么我们可以思考一个问题吗？我们是否需要每次都创建一个可以服务请求的线程？这里是否存在资源浪费，如何合理控制系统负荷，保证正常水位？ 1.2.汇集思想。
关于池化的定义可以参考百度百科。对于存储来说，池化的概念并不陌生。
可以说，存储池的概念并不是始于存储虚拟化技术。存储从服务器直连存储发展到以SAN或NAS为代表的网络存储的过程中，池化的概念被提出。
我们可以简单地将其理解为一种思想的抽象表达，可以用于物理或虚拟中，以提高某些资源的利用率。比如我们现在说的线程，我们应该如何使用池化的思想呢？从线程的痛点我们知道，我们要解决的主要问题有两个：资源浪费和资源使用不可控。
我们提前创建线程并将它们放入池（队列容器）中。当你需要的时候，我只是在容器池中为你提供一个线程。
当整个请求链路完成后，线程被放回到容器中。这样我只需要维护池中的线程即可，不再需要每次都创建和回收线程。
是否增加了线程的资源复用性，提高了资源利用率？以上确实解决了资源浪费的问题，但是资源使用不可控怎么办？例如，如何设置池中合理的线程数？如果外部流量请求线程远远超过我们系统的负载能力怎么办？这里我们之前提到过，我们的多线程实际上是基于服务器的多核能力。所以我们首先想到的是基于服务器的多核能力。
我们能计算出合理的线程数吗？公式来自《Java 并发编程实践》，但实际上这里存在一些问题。如果你在实践中使用这个公式，你会发现它仍然不符合？那么我们在实践中会遇到哪些问题呢？大家可以继续看公司的实践（基于美团的实践场景）。
在讲之前我们先来了解一下线程池的原理？ 1.3.线程池的原理。我们先看一下ThreadPoolExecutor的运行流程原理，如下图： 基于我们之前提到的两个痛点，资源浪费和资源使用不可控。
1.3.1. 【痛点一】资源浪费示例：假设现在我们要下单购买一款产品。我想买衣服（任务提交）。
某宝跳转支付页面（任务分配）->调用支付宝付款（线程分配A）您付款完成（任务分配）->扣除库存（线程分配B）您查看订单物流信息（任务分配）分配）->新秀秀在途（线程分配A）你关闭某个宝藏，等待衣服到达。上面已经简化了该过程。
主要描述的是说红色的【线程分配A】被重用了2次（实际中可能会被使用多次/1次（这里举一个简单的例子以便更好的解释），从而避免了创建线程3的开销正常情况下回收线程3次，如果我们现在有多个用户完成上述步骤，就可以充分发挥线程池的作用，提高复用性1.3.2。从上图我们看到有缓冲执行和任务拒绝，其实这两个代表的是解决我们刚才提到的如果当前用户请求负载超过实时处理能力的痛点。
线程池，那么我们就可以安排它进入缓存阻塞队列，也就是说告诉它我们一次只能容纳最多的人，如果满足人的情况，那我们还等什么呢。如果超过最大容量怎么办？为了保护我们系统的可用性，我们很抱歉拒绝提供服务。
其实这个还是比较容易理解的。例如，当您现在进行限时抢购时，有时您会发现“亲爱的，服务器正忙，请稍后重试！”。
其实就是对当前系统服务处理能力的自我保护。服务被拒绝。
1.3.3.线程池原理讲解。首先，线程池内部其实构建了一个生产者-消费者模型，将线程和任务解耦，不直接相关，从而很好的缓冲任务，复用线程。
线程池的运行主要分为两部分：任务管理和线程管理。任务管理部分扮演了生产者的角色。
当任务提交后，线程池将决定任务的后续流程：（1）直接申请线程执行任务； （2）缓冲在队列中等待线程执行； (3) 拒绝任务。线程管理部分是消费者。
它们统一维护在线程池中，并根据任务请求分配线程。当线程完成任务后，会继续获取新的任务来执行。
最后，当线程无法获取任务时，线程将被回收。 1.4. Java中的实践我们可以看一下Java中提供的线程池创建类及其核心参数。
这里不描述执行器，因为在实践中，自定义线程池越多越好，特别是在核心参数的自定义方面。 1.4.1.参数介绍上面的英文解释很好。
鉴于解释友好，这里进一步解释一下： corePoolSize（核心线程数）queueCapacity（任务队列数）MaxPoolSize（最大线程池数）KeepAliveTime（线程空闲时间）allowCoreThreadTimeout（允许核心线程超时）rejectedExecutionHandler （任务拒绝处理程序） 1.4.2、线程池默认值 ? corePoolSize = 1 ?queueCapacity = Integer.MAX_VALUE ? maxPoolSize = Integer.MAX_VALUE ? keepAliveTime = 60 秒 ?allowCoreThreadTimeout = false ?rejectedExecutionHandler = AbortPolicy() 我们可以初始化并设置基于上面提供的线程池参数的自定义线程池。 1.5.公司的做法 1.5.1。
公司实践中存在的问题 参考美团的两个事故案例：从事故案例中我们可以看到哪些问题？主要问题是我们实践中的线程拒绝策略和核心线程数设置。那么我们应该如何合理的设置线程池参数呢？从解决方案来看，目前我们可以有这三种解决方案，但是上述问题也很明显。
事实上，没有什么灵丹妙药可以解决这个问题，但是我们可以思考一下，是否有一个折衷的方案来根据不同的场景动态开发线程池？ 1.5.2.公司提供的解决方案仍然参考了美团的解决方案。针对线程池的痛点，美团提出了动态修改线程池参数+手动可观测+报警机制防范。
1.5.2.1。核心参数如何设置，需要根据以下几个值来确定 -tasks：每秒任务数，假设为~ -taskcost：每个任务花费的时间，假设为0.1s -responsetime：最大系统允许的响应时间，假设做几次计算是1s - corePoolSize = 每秒需要多少个线程？? ? ? ? ? ? ? ? ? ? ? ? * 线程数 = 任务/(1/任务成本) = 任务*taskcout = (~)*0.1 = 50~ 线程。
corePoolSize设置应大于50 * 根据原则，如果每秒80%的任务数小于，则corePoolSize可以设置为80 - queueCapacity = (coreSizePool/taskcost)*responsetime * 计算出的queueCapacity = 80 /0 .1*1 = 80。这意味着队列中的线程可以等待1s。
如果超过限制，则需要开启新的线程执行。 * 切记不要将其设置为Integer.MAX_VALUE。
这样，队列就会非常大，线程数也只会停留在 corePoolSize 大小。当任务急剧增加时，不能再开启新的线程执行，响应时间就会急剧增加。
- maxPoolSize = (max(tasks)-queueCapacity)/(1/taskcost) * 计算所得 maxPoolSize = (80)/10 = 92 * (最大任务数 - 队列容量)/每个线程每秒处理能力 = 最大线程数 - rejectedExecutionHandler：根据具体情况而定。如果任务不重要，可以放弃。
如果任务很重要，应该使用一些缓冲机制来处理它。 - KeepAliveTime和allowCoreThreadTimeout通常可以满足1.5.2.2的要求。
如何动态设置参数才能生效。参考：Spring的ThreadPoolTask??Executor类（对JDK ThreadPoolExecutor的一层包装，可以理解为装饰器模式）的setCorePoolSize方法。
也就是说，原生JDK本身就提供了动态修改线程池参数的方法。这个时候你有没有发现自己已经不擅长学习了？或者源代码是最好的书吗？ 2.总结希望这篇文章可以帮助大家理解线程池是如何引入的？多线程解决了什么问题？线程池原理是如何解决痛点的？那么企业在实践中会遇到哪些问题呢？而美团公司又是如何解决的呢？希望这篇文章对您有所帮助，系统梳理一下知识。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-06
06-17
06-21
06-06
06-18
06-17
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用