<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on 工程师手记</title><link>https://junozee.com/tags/java/</link><description>Recent content in Java on 工程师手记</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Mon, 24 Aug 2026 10:30:00 +0800</lastBuildDate><atom:link href="https://junozee.com/tags/java/index.xml" rel="self" type="application/rss+xml"/><item><title>线程池参数不是公式，而是业务设计</title><link>https://junozee.com/posts/thread-pool-is-a-design/</link><pubDate>Mon, 24 Aug 2026 10:30:00 +0800</pubDate><guid>https://junozee.com/posts/thread-pool-is-a-design/</guid><description>&lt;p&gt;“CPU 密集型任务设为 CPU 核数加一，I/O 密集型任务设为 CPU 核数乘二”是一个不错的起点，却不是生产配置的终点。&lt;/p&gt;&#10;&lt;p&gt;线程池真正需要回答三个问题：&lt;/p&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;任务阻塞时，谁会先被拖垮？&lt;/li&gt;&#10;&lt;li&gt;高峰来临时，应该排队、快速失败，还是降级？&lt;/li&gt;&#10;&lt;li&gt;下游服务能承受多大的并发？&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;p&gt;一个为搜索构建的线程池和一个为支付回调构建的线程池，拒绝策略往往应该完全不同。前者可以快速失败并返回兜底结果，后者则更需要保序、重试和可追踪的补偿机制。&lt;/p&gt;&#10;&lt;p&gt;因此，参数配置应该从业务的失败语义开始，再结合监控数据持续调整。公式负责给出初值，工程设计才决定最终值。&lt;/p&gt;</description></item></channel></rss>