“调用 factory 方法才真正触发计算”实指任务执行上下文（线程载体）直至 factory.newThread(runnable) 被调用时才绑定就绪，factory 仅为封装线程元信息的模板，不启动线程、不执行逻辑，真正触发计算的是 start()/submit()/execute() 等调度动作。
所谓“调用 factory 方法才真正触发计算”，并不是说计算逻辑被延迟到 factory 调用那一刻才生成，而是指：**任务的执行上下文（尤其是线程载体）直到 factory.newThread(...) 被显式调用时，才被实际绑定和准备就绪**。这个“真相”背后，是 Java 并发模型中「任务定义」与「任务执行」的彻底解耦，也是高并发 IO 框架（如 Netty、WebFlux、CompletableFuture 链）保持轻量、响应迅速的关键设计。
factory 不是执行器，而是线程规格说明书
像 Thread.ofVirtual().factory() 或 Executors.defaultThreadFactory() 返回的从来不是线程本身，而是一个可复用的构造模板。它只封装了线程名前缀、是否守护线程、优先级、未捕获异常处理器等元信息。它不启动任何线程，也不运行任何 Runnable —— 直到你调用 newThread(runnable)，JVM 才会按该模板配置一个线程实例，并把 runnable 绑定为它的入口逻辑。
这意味着：
- 定义一个 factory 是零开销操作，纯内存对象创建
- Runnable 里的代码不会因 factory 创建而执行，甚至不会被 JIT 预编译
- 真正决定“何时开始计算”的，永远是
thread.start()或 executor.submit() 这类触发调度的动作
IO 框架里 factory 延迟绑定的真实价值
在 Netty 的 NioEventLoopGroup 或 WebFlux 的 ThreadPoolTaskExecutor 中，factory 往往配合事件循环或响应式流使用。此时，factory 的延迟生效机制支撑了两个关键能力：
- 按需分配资源：连接刚建立时，只注册 Channel 到 selector，不立刻创建业务线程；只有当数据真正可读（epoll_wait 返回）、且需要解析/落库时，才通过 factory 派生线程执行耗时逻辑
-
隔离 I/O 与业务生命周期：I/O 线程（如 NioEventLoop）永不执行数据库查询；它只调用
businessPool.submit(...)，而 submit 内部才用 factory 构建业务线程——计算被“推”到另一个执行平面，避免阻塞事件循环
看穿“触发点”的三个信号
判断某段逻辑是否真正在 factory 调用时执行，只需盯住这三个动作：
- 是否有
start()、submit()、execute()或publishOn(scheduler)类调用？没有则无执行 - Runnable / Supplier / Mono 内部是否含阻塞操作（如
JDBC query、File.readAllBytes）？若有，它们只会在被提交到线程池后才真正运行 - 是否用了
CompletableFuture.supplyAsync(..., factory)？注意：supplyAsync 第二个参数是 Executor，不是 ThreadFactory；真正用到 factory 的是 Executor 内部实现（比如 ThreadPoolExecutor 的 addWorker 流程）
本质上，factory 就像一张空白工单，写满规格却不开工；真正的“计算启动键”，永远在你按下 submit、start 或 publishOn 的那一瞬。
