java 线程池异常捕获,
00-1010 1.出问题了。找原因3。线程池4的参数。有什么问题？结束
00-1010没办法。如果我在IT行业工作，我每天都要面对失败。每个人都是传说中的消防员，到处救火。不过这次故障范围有点大，主机打不开。
幸运的是监控系统留下了一些证据。
发现机器的CPU、内存、文件句柄随着业务的增长不断攀升，直到监控才能收集到信息。
问题是，这些主机上部署了许多Java进程。没有别的原因，只是为了节省成本，应用是混的。当主机出现整体异常时，很难找到罪魁祸首。
因为远程登录也结束了，暴躁的运维只能重启机器，然后重启应用。经过长时间的等待，所有的进程都是活动的，但是仅仅过了一会儿，主机就会立即死亡。
生意一直处于死路一条的状态，真的很烦。也让人焦虑。几次尝试后，运维崩溃，启动应急预案：回滚！
最近上线记录很多，还有开发者私自上线部署，所以运维都是一个循环：回滚哪些？幸运的是，有人有一个聪明的大脑，并记得有发现的命令。然后找到所有最近更新的jar包并回滚它们。
Find/apps/deploy-mtime 3 grep jar $如果你不知道find命令，那真的是一场灾难。还好有人知道。
回滚了十几个jar包，还好数据库没有模式变化，系统终于正常运行。
00-1010没有别的办法。检查日志并进行代码审查。
代码回顾要追溯到最近一两周的代码变化，因为有些功能代码要沉淀一段时间才能在线享受。
看着满屏的提交记录“OK”，技术经理的脸都绿了。
“xjjdog说，《80%的程序员，不会写commit记录》，我觉得你写不出100%”。
所有人都沉默了，忍受着寻找历史变迁的痛苦。经过大家的不懈努力，终于在屎间找到了一些问题代码。CxO自己建了一个群，大家把可能出错的代码扔到群里。
CxO说，系统服务中断了近一个小时，影响非常恶劣。“问题必须彻底解决，投资人很关心这个问题”！
Okok，在钉钉的帮助下，大家的手势都变得统一了。
00-1010代码有点多，大家讨论问题代码已经很久了。其中一些使用并行流，一些dazzle代码嵌入在lamba表达式中，一些线程池使用代码被重点考察。
最后，我们决定再次检查线程池的代码。有一段话是这样写的。
rejectedexecutionhandler handler=newThreadPoolExecutor。DiscardOldestPolicy()；ThreadPoolExecutorexecutor=newThreadPoolExecutor(100，200，60000，TimeUnit。毫秒，newlinkedblockingeque(10)，handler)；且不说参数不同，就算考虑拒绝策略。
Java线程池使编程变得非常简单。它有许多参数，如上所示。还是一个一个介绍吧，不然代码没法审核。
CorePoolSize:核心线程的数量，核心线程在创建后会一直存在。
MaxPoolSize:最大线程数
KeepAliveTime:线程空闲时间
工作队列：阻塞队列
线程工厂：线程创建工厂
处理程序：拒绝策略
下面介绍一下他们的关系。
当线程数小于核心线程数时，当新任务到来时，会产生一个新线程进行服务。当当前线程数大于核心线程数且阻塞队列未满时，任务将被放入阻塞队列。当线程数大于核心线程数且阻塞队列已满时，将创建一个新线程来提供服务，直到线程数达到maximumPoolSize大小。此时，如果有新的任务，就会触发拒绝策略。
先说拒绝策略。Jdk默认实现四种策略，默认实现是AbortPolicy，即直接抛出异常。这里还有一些其他的。
丢弃策略比
bort更加激进，直接丢掉任务，连异常信息都没有
CallerRunsPolicy由调用的线程来处理这个任务。比如一个web应用中，线程池资源占满后，新进的任务将会在tomcat线程中运行。这种方式能够延缓部分任务的执行压力，但在更多情况下，会直接阻塞主线程的运行
DiscardOldestPolicy丢弃队列最前面的任务，然后重新尝试执行任务
这段线程池的代码是新加的，参数设置还算正常，并没有什么大的问题。唯一有可能的风险，就是使用DiscardOldestPolicy的拒绝策略。当任务非常多的时候，这个拒绝策略会造成任务排队，请求超时。
当然不能放过这种风险，说实话也是到现在为之能够找到的最可能的风险代码了。
"把DiscardOldestPolicy改成默认的AbortPolicy吧，重新打包上线一下试试。技术大牛在群里说。
4. 问题在哪里？
结果，服务灰度上线之后，宿主机不多时，就死掉了。是它的原因没跑了，但是why？
线程池的大小 ，最小100，最大200，说什么也不过分。阻塞队列的容量只有10，说什么也不会造成问题。你要说是这个线程池造成的原因，打死我都不信。
但是业务部门反馈，这段代码加上就死，不加就没事。技术大牛们抓耳挠腮百思不得其姐。
到最后，终于有人忍不住了，下载下业务的代码打算调试一下。
当他打开Idea的时候，瞬间懵逼了，又瞬间领悟了。他终于明白了这段代码为什么会产生问题了。
线程池，竟然是在方法里创建的！
当每一个请求到来的时候，它都会创建一个线程池，直到系统再也无法分配资源为止。
可真是霸道啊。
所有人都在关注线程池的参数是怎么设置的，但从来没有人怀疑这段代码所在的位置。
5. 结尾
问题低级又常见，现在我严重怀疑拒绝策略也是网上拷贝的代码。
那么多码农，熬夜选择了个业务低峰期进行上线，还是躲不过命啊，躲不过猪队友的伤害。
当然，这还说明了另外一个问题：技术能力跟不上，再牛的管理也爱莫能助。
最后，连投资人都施压的故障，几乎没有人愿意去实际的翻一下业务的代码看看。这得多大的屎山，才让人这样避而远之，生怕把自己的羽毛染臭啊！
以上就是java线程池参数位置导致的夺命故障宿主机打不开的详细内容，更多关于java线程池参数位置的资料请关注盛行IT其它相关文章！
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。