【异常】使用Executors创建线程池时SonarLint提示异常，Executors.newFixedThreadPool提示手动创建线程池，效果会更好哦。

最新推荐文章于 2024-11-11 21:31:22 发布
原创 最新推荐文章于 2024-11-11 21:31:22 发布 · 427 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#多线程 #线程池 #Executors #SonarLint

一、报错内容

由于公司的代码检测平台检测到使用下面这种方式创建线程，从而提示“手动创建线程池，效果会更好哦”
具体使用Executors创建线程池代码如下：
在这里插入图片描述

ExecutorService executorService = Executors.newCachedThreadPool();

二、报错说明

在使用Java的Executors工厂类来创建线程池时，如Executors.newFixedThreadPool(int nThreads)，确实可以很方便地得到一个固定大小的线程池。然而，有时候确实会听到建议说手动创建线程池（即使用Thre

了解本专栏 订阅专栏 解锁全文 超级会员免费看
SpringBoot学习之使用Executors创建线程池（四十二）
徐泗空的博客
10-24 849
Executors.newCacheThreadPool()：可缓存线程池，先查看线程池中有没有之前创建的线程，如果有则直接使用。否则就新创建一个新的线程加入线程池中，我们经常用此类线程池来执行一些业务处理时间很短的任务。Executors.newFixedThreadPool()：创建一个固定（指定）长度可重用的线程池，可以控制最大创建数，超过最大长度之后就会放入到队列进行等待。
Java高并发编程实战14，强制禁止，线程池不允许使用Executors创建
学Java，找哪吒
10-16 1705
大家好，我是哪吒。在程序开发中，高并发场景越来越多，线程池首当其冲。简单回顾一下：《阿里巴巴 Java 开发手册》强制禁止，线程池不允许使用Executors创建，而是通过ThreadPoolExecutor的方式创建，这样的处理方式能让编写代码的工程师更加明确线程池的运行规则，避免资源耗尽的风险。Executors返回的线程池对象的弊端如下：好吧，昨天，我还通过创建了一个线程池，看来以后要注意了。具体分析以下【说明】中的内容，以FixedThreadPool为例，允许的请求队列长度为Integer.MAX
手动创建线程池，效果会更好哦
qq_48718409的博客
09-08 2128
由于公司的代码检测平台检测到使用下面这种方式创建线程，从而提示“手动创建线程池，效果会更好哦” 因为使用Executor这种方式创建线程有以下弊端： 1、FixedThreadPool和SingleThreadPool这两种方法创建线程池： 允许的请求队列长度为Integer.MAX_VALUE，可能会堆积大量请求，从而导致OOM 2、CachedThreadPool和ScheduledThreadPool这两种方法创建线程池： 允许的创建线程数量为nteger.MAX_VALUE，可能会创建大量的线程，从
为什么阿里巴巴要禁用Executors创建线程池？
Java笔记虾
11-08 2999
看阿里巴巴开发手册并发编程这块有一条：线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，通过源码分析禁用的原因 写在前面 首先感谢大家在盖楼的间隙阅读本篇文章，通过阅读本篇文章你将了解到： 线程池的定义 Executors创建线程池的几种方式 ThreadPoolExecutor对象 线程池执行任务逻辑和线程池参...
手动创建线程池，效果会更好哦。 建议使用ThreadPoolExecutor线程池创建
weixin_44227650的博客
08-24 5455
使用CallerRunsPolicy拒绝策略，该策略会将任务交给调用execute的线程执行【一般为主线程】，此时主线程将在一段时间内不能提交任何任务，从而使工作线程处理正在执行的任务。线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。CPU密集型：线程池的大小推荐为CPU数量+1。若队列已满，判断线程池是否已满，线程池是否已满和maximumPoolSize参数有关，若未满创建线程执行任务。
阿里代码规约：手动创建线程池,效果会更好哦
鲜衣怒马楼兰月
08-30 2万+
规避资源耗尽的风险，高并发下推荐手动创建线程池
为什么不推荐使用Executors创建线程池？（面试常问）
A_diligent_man的博客
07-15 825
因此，为了更好地控制和管理线程池，推荐使用**ThreadPoolExecutor**类来手动创建线程池，它可以自定义线程名称，还可以根据具体的需求自己设置线程池的参数：例如核心线程数、最大线程数、队列类型、线程工厂等、以及自定义拒绝策略来处理任务无法执行的情况。
线程进阶篇4：如何用Executors工具类创建线程池-代码演示-源码分析-可行性分析，对比new ThreadPoolExecutor()方式有什么不同
raining优快云的博客
11-11 3385
本篇文章主要是讲解如何使用Executors工具类创建线程池，从代码演示-源码分析-可行性分析，以及对比new ThreadPoolExecutor()方式有什么不同等方面带你深入Executors。
创建线程池 newFixedThreadPool，阿里巴巴代码规范提示： 手动创建线程池，效果会更好哦。
王魂风气的博客
07-24 3675
今天创建了线程池，创建时候阿里巴巴提示我： 手动创建线程池，效果会更好哦。我也没在意。果然就遭到了报应，内存泄漏了… 本来我是这样创建的： ExecutorService executorService = Executors.newFixedThreadPool(maxThreadNums); executorService .execute(new Runnable() { @Override public void run() {
Executors Java编程规范插件提示手动创建线程池的解决办法
热门推荐
悟鸣的技术博客
05-10 2万+
一、背景 最近了解一下线程池，下载其中的代码并运行。 https://howtodoinjava.com/core-java/multi-threading/when-to-use-countdownlatch-java-concurrency-example-tutorial/ 其中ApplicationStartupUtil这个类 package com.chujianyun;...
手动创建线程池
WZH577的博客
12-16 883
ScheduledExecutorService executorService = Executors.newScheduledThreadPool(100); 以上代码阿里的代码规范插件会提示手动创建线程池，用以下方式创建线程池 ThreadFactory namedThreadFactory = new ThreadFactoryBuilder().setNameFormat("--...
线程池不允许使用Executors去创建
狗天大
04-01 204
情景重现： IDEA+阿里编码规约+Executors.newFixedThreadPool(5)提示手动创建线程池，效果会更好哦。 原因： 1.FixedThreadPool和SingleThreadPool里面的阻塞队列的最大长度为Integer.MAX_VALUE也就是2147483647（21亿），极有可能会发生OOM异常。 2.CachedThreadPool和ScheduledThreadPool允许创建的最大线程数量为Integer.MAX_VALUE也就是2147483647..
java线程池、简单定时调度任务
hgg923的专栏
12-13 2629
java线程池、简单定时调度任务。
使用Executors创建线程时遇到的问题
怀揣梦想，一颗执着于技术的心从未磨灭，内心住着一颗顽强的小强时刻提醒自己层层突破自我，同时也成就他人
03-11 564
综上所述，有可能造成OOM之外，使用Executors来创建线程池也不能自定义现场的名字，不利于排查问题，建议直接使用ThreadPoolExecutor来定义线程池，这样可以更灵活控制。LinkedBlockingQueue是一个无界阻塞队列，如果使用该线程池执行任务，如果任务过多时就会不断的添加到队列中，任务越多占用的内存就越多，最终可能耗尽内存，导致OOM。
为何阿里代码规约要求手动创建线程池，我的踩坑和升级
高山仰止，景行行止
10-29 2174
前言 很久没有写点东西了，主要是工作不忙，所忙的工作也都是比较简单的，并未遇到我没有接触过的技术，之前一直有一个需求就是对字段加密，而需要加密的字段有311万多，最初都是用单线程去写的，一次查询2000条，然后加密后一条一条的更新，结果一算，311万得花费5.7个小时，太慢了，于是就看了同事之前写的多线程，拷贝过来发现我的阿里编码规约提示：手动创建线程池,效果会更好哦 解决过程 参考博客 我之前通篇看过阿里编码规约，这块说到了我才有印象。晚上查了一下，参考了这几篇博客 1、阿里不推荐使用Executors创
阿里巴巴提示：手动创建线程效果更好
fengjian的博客
02-15 1804
原来创建方式 ExecutorService executorService = Executors.newFixedThreadPool(threadNum); 阿里的插件提示：手动创建线程效果好 我看了一下解释：说是容易造成OOM，巧了，我之前就是出现这个问题。 于是我使用了阿里推荐的方式穿件线程 ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("thread-call-runner-%d").build(
ExecutorService线程池详解
qiaziliping的博客
04-10 1877
对线程池 “池”的理解 可以理解为工厂，如果工厂生产斧头，小王从工厂借了一把，当小王用完了，还给工厂，之后小李也可以借去用 复用已有资源 控制资源总量 你一个任务过来了，我发现池子里有没事干并且还活着的线程，来，拿去用，我也不用费事给你创建一条线程了，要知道线程的创建和销毁可都是麻烦事 你一个任务过来了，我发现池子的线程都在忙，并且现在池子的线程已经太多了，在不限制下去就要内存溢出了...
java踩坑之线程池
bug_null的博客
02-17 1165
java踩坑之线程池 就有前几天刚完成的大型对比时使用到了线程池，对于线程池，我想我有好多踩过的坑的经历，这也就是所说的经验吧，我想通过这篇文章，将我所踩过的坑，都记录下来. 坑1-newFixedThreadPool 程序问题演示: 这是jdk提供的一个默认线程线程池的实现。创建一组固定大小的线程池，来运行任务。当时这个任务是用来运行后台的异步发送通知任务。每秒大约100个发送量，高峰时段大约500个发送量，量并不大。但有一天通知服务突然宕机了，而我们服务调用超时的时间是2分钟，结果就导致我们的服务出现了
private static final ExecutorService executor = Executors.newFixedThreadPool(1); 提示手动创建线程池效果更好
最新发布
08-08
<think>嗯，用户询问的是Java中手动创建线程池与使用Executors.newFixedThreadPool的区别。这个问题涉及线程池的核心配置原理，需要从底层实现、风险控制和灵活性三个维度展开说明。 用户应该是个有Java并发编程经验的开发者，正在做性能优化相关的工作。ta特意提到“手动创建更好”，说明可能遇到了资源耗尽或性能问题，想了解深层次原因。从引用内容看，用户已经查阅过资料，但需要更系统的对比分析。 核心矛盾点在于：Executors的便捷性 vs ThreadPoolExecutor的可控性。工厂方法内部其实也是调用ThreadPoolExecutor，但隐藏了关键参数： - newFixedThreadPool默认使用无界队列LinkedBlockingQueue，这在突发流量下会导致OOM - 最大线程数设置与核心线程数相同，失去弹性扩容能力 - 拒绝策略采用AbortPolicy，直接抛异常不够友好 手动创建的优势恰恰体现在这些细节控制上： 1）队列容量可设置边界防止内存溢出 2）可定义合理的拒绝策略如降级方案 3）支持自定义线程工厂便于监控 4）允许核心线程超时回收资源 特别要注意的是线程工厂这个容易被忽视的点。Executors.DefaultThreadFactory产出的线程命名混乱，而自定义工厂可以赋予业务语义名称，在诊断线程泄露时特别有用。 用户可能还需要知道具体场景选择建议。对于常规低并发场景，Executors仍然够用；但高并发或延迟敏感系统，必须手动配置。这里可以补充阿里开发手册的案例：某电商平台因使用newFixedThreadPool导致促销期间队列堆积20万任务最终OOM。 最后要强调参数优化方法。比如IO密集型任务最大线程数通常设为2N+1，队列用SynchronousQueue；而计算密集型则要小队列防止上下文切换过度。这些实战经验比单纯比较API更有价值。</think>在 Java 并发编程中，手动创建线程池（使用 `ThreadPoolExecutor` 构造函数）与使用 `Executors.newFixedThreadPool()` 各有优劣，但**手动创建通常更推荐**，尤其在需要精细化控制、避免资源耗尽或优化性能的场景下。以下是详细对比分析： --- ### **一、`Executors.newFixedThreadPool()` 的局限性** ```java ExecutorService executor = Executors.newFixedThreadPool(5); // 便捷但存在隐患 ``` 1. **无界任务队列导致 OOM 风险** - 默认使用 `LinkedBlockingQueue`（无容量限制），任务激增时队列无限膨胀，可能耗尽内存[^2][^3]。 - **示例**：若任务提交速度 > 线程处理速度，队列堆积将引发 `OutOfMemoryError`。 2. **线程工厂与拒绝策略不可定制** - 默认线程工厂 (`DefaultThreadFactory`) 生成的线程命名不友好（如 `pool-1-thread-1`），不利于问题排查。 - 拒绝策略默认为 `AbortPolicy`（直接抛出异常），无法灵活降级（如记录日志或暂存任务）[^2][^3]。 3. **扩展性受限** - 固定线程数无法动态调整，无法根据负载自动扩容/缩容。 --- ### **二、手动创建线程池 (`ThreadPoolExecutor`) 的优势** ```java // 手动创建线程池（推荐方式） ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, // 核心线程数 (corePoolSize) 10, // 最大线程数 (maximumPoolSize) 60, // 非核心线程空闲存活时间 (keepAliveTime) TimeUnit.SECONDS, // 时间单位 new ArrayBlockingQueue<>(100), // 有界任务队列（容量100） new CustomThreadFactory("business-thread"), // 自定义线程工厂 new CustomRejectedExecutionHandler() // 自定义拒绝策略 ); ``` 1. **规避资源耗尽风险** - 使用有界队列（如 `ArrayBlockingQueue`）控制队列长度，避免 OOM。 - 结合 `maximumPoolSize` 和拒绝策略，实现负载保护。 2. **灵活定制关键组件** - **线程工厂**：自定义线程名称、优先级、守护属性，便于监控和日志跟踪。 ```java class CustomThreadFactory implements ThreadFactory { public Thread newThread(Runnable r) { return new Thread(r, "business-thread-" + counter.incrementAndGet()); } } ``` - **拒绝策略**：支持 `RejectedExecutionHandler` 接口扩展（如降级、重试或异步持久化）。 ```java class CustomRejectedHandler implements RejectedExecutionHandler { public void rejectedExecution(Runnable r, ThreadPoolExecutor e) { log.warn("Task rejected, saving to retry queue: {}", r); retryQueue.add(r); // 自定义处理逻辑 } } ``` 3. **动态调整参数** - 支持运行时修改核心参数（需谨慎）： ```java executor.setCorePoolSize(8); // 动态调整核心线程数 executor.setMaximumPoolSize(20); // 动态调整最大线程数 ``` --- ### **三、适用场景对比** | **场景** | **推荐方式** | **原因** | |------------------------------|----------------------------------|--------------------------------------------------------------------------| | 简单任务、低并发量 | `Executors.newFixedThreadPool()` | 快速实现，代码简洁 | | 高并发、生产环境关键服务 | 手动创建 `ThreadPoolExecutor` | 避免 OOM，支持定制化，便于监控和调优 | | 需要动态扩缩容 | 手动创建 | 可调用 `setCorePoolSize()` 等方法动态调整 | | 需自定义线程命名或拒绝策略 | 手动创建 | 工厂类无法定制线程工厂和拒绝策略 | --- ### **四、最佳实践建议** 1. **队列选择** - CPU 密集型任务：使用有界队列（如 `ArrayBlockingQueue`）防止任务堆积。 - IO 密集型任务：可适当增大队列容量或使用 `SynchronousQueue`（配合更高的 `maximumPoolSize`）。 2. **参数配置经验值** - **核心线程数**：CPU 密集型建议 `N_cpu + 1`，IO 密集型建议 `2 * N_cpu`。 - **最大线程数**：根据任务阻塞时间调整，一般不超过 `核心线程数 * 2`。 - **队列容量**：需在内存占用和吞吐量间权衡（如 100~1000）。 3. **监控与调优** - 通过 `executor.getQueue().size()` 监控队列堆积。 - 使用 `ThreadPoolExecutor` 的 `beforeExecute()`/`afterExecute()` 钩子记录任务耗时。 > **阿里《Java开发手册》强制规定**：线程池不允许使用 `Executors` 创建，必须通过 `ThreadPoolExecutor` 手动构造，以明确运行规则，规避资源耗尽风险[^3]。 --- ### **总结** - **`Executors.newFixedThreadPool()`**：适合原型验证或非关键场景，但存在 OOM 和定制化缺陷。 - **手动创建线程池**：通过精准控制参数（核心线程数、队列类型、拒绝策略等），提升系统健壮性和可维护性，是生产环境首选方案[^1][^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

本本本添哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值