并发编程【免费下载链接】piscinaA fast, efficient Node.js Worker Thread Pool implementation项目地址https://gitcode.com/gh_mirrors/pi/piscina点击查看免费下载导读Piscina 是一个基于 Node.js Worker Threads 的高性能线程池实现。本文聚焦于Piscina类暴露的全部只读实例属性逐一说明其语义、取值来源、在源码中的实现位置以及真实使用场景。读完本文你将掌握如何用completed、duration、queueSize、idleThreads监控池的健康状态如何用runTime、waitTime直方图定位性能瓶颈如何用needsDrain配合drain/needsDrain事件实现优雅的背压backpressure以及如何计算并解读utilization这一池利用率指标。本文所有属性均为只读readonly由实例内部状态派生调用方不能直接赋值。对应实现可查阅 src/index.ts 与 src/histogram.ts。一、基础状态属性completed、duration、options这三个属性回答的是最朴素的三个问题完成了多少任务池子运行了多久当前用的是什么配置1.1completed只读number当前已完成的任务总数是累计值只增不减。在源码中ThreadPool维护completed : number 0计数器src/index.ts每次任务回调执行时递增this.completedsrc/index.ts对外通过get completed ()直接暴露src/index.ts。无论任务成功还是失败只要被 Worker 处理并返回结果/错误都会计入completed。测试 test/post-task.test.ts 展示了任务完成后pool.completed变为1。典型用途与runTime.mean、utilization配合估算池子的吞吐总量。1.2duration只读number自该Piscina实例创建以来经过的毫秒数。实现非常直接src/index.tsget duration () : number { return performance.now() - this.#pool.start; }其中start在构造时由performance.now()记录src/index.ts。duration是utilization计算中的核心分母也是判断“池子冷启动后是否已经稳定运行”的简便依据。测试 test/simple-test.test.ts 断言运行若干任务后worker.duration 0。1.3options只读FilledOptions当前实例实际生效的配置副本。文档原话与传给构造函数的 options 对象具有完全相同的属性。要点源码佐证src/index.tsthis.options withNullPrototype({ ...kDefaultOptions, ...options, filename, maxQueue: 0, });默认值在kDefaultOptions中定义src/index.tsminThreads默认max(floor(cpuParallelism/2), 1)maxThreads默认cpuParallelism * 1.5maxQueue默认InfinityconcurrentTasksPerWorker默认1recordTiming默认truecloseTimeout默认30000构造时会做归一化maxQueue auto时被换算为maxThreads ** 2src/index.ts且minThreads/maxThreads相互钳制。因此读取options拿到的是归一化后的最终值例如auto已变成具体数字使用withNullPrototypesrc/common.ts创建一个无原型对象避免原型链污染。典型用途程序化地检查options.maxQueue、options.maxThreads是否满足当前负载预期文档也明确建议在配置maxQueue: auto后通过options.maxQueue查看换算结果docs/docs/api-reference/class.md。二、线程与队列视角threads、idleThreads、queueSize这三个属性描绘了线程池“有多少人在干活、多少人在排队”的动态画面。2.1threads只读Worker[]由线程池当前使用的Node.jsWorker实例数组来自node:worker_threads。实现直接遍历资源池中的WorkerInfo收集其底层workersrc/index.ts。数组元素是原生Worker可直接调用worker.threadId、worker.terminate()等原生 API。注意threads返回的是新数组每次 getter 调用都会重建不要依赖数组引用相等性判断变化应比较长度或元素。2.2idleThreads只读number当前已完成预热ready且没有在跑任何任务的 Worker 数量。实现细节src/index.tsget idleThreads () : number { let count 0; for (const workerInfo of this.#pool.workers.readyItems) { if (workerInfo.currentUsage() 0) count; } return count; }readyItems来自资源池AsynchronouslyCreatedResourcePoolsrc/worker_pool/base.tsWorker 完成启动预热后由pendingItems移入currentUsage()返回该 Worker 当前承接的任务数若正在运行带 abort 信号的任务则返回Infinitysrc/worker_pool/index.ts测试 test/thread-count.test.ts 完整演示了minThreads: 2时idleThreads在2 → 1 → 0 → 2之间的变化且destroy()后归零。典型用途判断池子是否还有空闲计算力避免盲目新增任务。2.3queueSize只读number当前等待分配给 Worker 的任务数即排队中的任务量。实现src/index.tsget queueSize () : number { const pool this.#pool; return Math.max((pool.taskQueue.size pool.skipQueue.length) - pool.pendingCapacity(), 0); }taskQueue是主任务队列skipQueue用于临时存放被跳过如等待 abort 信号处理的任务src/index.tspendingCapacity()是“正在启动中、尚未 ready 的 Worker 可承接的任务容量”src/index.ts从排队数中扣除因此队列越满、越接近maxQueuequeueSize越能真实反映排队压力结果是Math.max(..., 0)保证不会出现负值。测试 test/task-queue.test.ts 展示了maxThreads: 3时任务从直接分发到排队的临界行为当第 4 个任务提交时queueSize变为1。关键联动queueSize与drain/needsDrain事件直接相关——drain在queueSize归零时发出needsDrain在容量满载时发出docs/docs/api-reference/event.md。三、背压与容量needsDrain3.1 语义needsDrain只读boolean表示池子是否需要“排空”后才能继续处理新任务。文档定义当没有足够容量在不超出maxQueue或maxThreads的前提下处理更多任务时该值为true。其计算综合了线程数当前及待启动线程、maxQueue大小以及当前在途in-flight任务数。3.2 源码实现_needsDrain标志位在ThreadPool中维护对外由get needsDrain ()暴露src/index.ts。核心逻辑在_maybeDrain()src/index.tsif (maxCapacity currentUsage queueSize maxQueueSize) { this._needsDrain true; queueMicrotask(() this.publicInterface.emit(needsDrain)); }即当“所有 Worker 的在途任务数之和maxCapacity maxThreads * concurrentTasksPerWorker”与“队列长度”同时达到上限时置位并异步发出needsDrain事件当queueSize重新归零时复位并发出drain事件src/index.ts。3.3 使用要点与注意事项用途这是实现背压的“信号灯”。上游生产者看到pool.needsDrain true时应当暂停提交任务等待drain事件后再继续重要限制文档原注Piscina不会在maxQueue阈值之上缓冲任务所以needsDrain并不是“池子一定会接受更多任务”的保证。超过maxQueue的提交会直接以错误拒绝相关错误码见 docs/docs/api-reference/error-codes.mdPISCINA_ERR_TASK_QUEUE_LIMIT任务队列已达上限PISCINA_ERR_NO_TASK_QUEUE_AVAILABLE队列被禁用且所有 Worker 已满。测试 test/post-task.test.ts 验证了needsDrain事件触发时pool.needsDrain true且pool.queueSize 3maxQueue: 3。设计哲学_maybeDrain()的注释src/index.ts指出目标正是让使用者把“等待数”维持在 0——不给任务源提交永远无法立即执行的任务从而自然形成背压。这与 Node.js Writable stream 的drain行为对齐。四、性能观测runTime与waitTime直方图4.1 属性概览runTime与waitTime是直方图摘要对象histogram summary所有值单位均为毫秒runTime已完成任务的实际执行耗时分布waitTime任务在队列中等待被分配到 Worker 的耗时分布从任务创建taskInfo.created到分发开始taskInfo.started。两者结构完全一致均包含字段类型含义averagenumber所有任务的平均耗时与mean相同meannumber均值stddevnumber标准差反映耗时波动程度minnumber最快记录maxnumber最慢记录p{N}number百分位分布详见下文4.2 百分位字段p{N}的含义凡符合p{N}模式N 为数字如p1、p99的属性都代表耗时的百分位分布。文档示例p99表示 99% 的观测耗时都小于或等于该值。本实现提供的分位点src/histogram.ts为p0_001、p0_01、p0_1、p1、p2_5、p10、p25、p50中位数、p75、p90、p97_5、p99、p99_9、p99_99、p99_999尾部分位点p99.9以上特别适合发现“长尾慢任务”——平均值会被极端值拉高但p99_999能精确暴露偶发的尖峰延迟。文档中的典型输出示例运行耗时毫秒{ average: 1880.25, mean: 1880.25, stddev: 1.93, min: 1877, max: 1882.0190887451172, p0_001: 1877, p0_01: 1877, p0_1: 1877, p1: 1877, p2_5: 1877, p10: 1877, p25: 1877, p50: 1881, p75: 1881, p90: 1882, p97_5: 1882, p99: 1882, p99_9: 1882, p99_99: 1882, p99_999: 1882 }4.3 底层实现基于node:perf_hooks的直方图Piscina 使用 Node.js 内置的perf_hooks.createHistogram()RecordableHistogram作为底层数据结构src/histogram.tsPiscinaHistogramHandler内部维护#runTime与#waitTime两个直方图src/histogram.ts记录值统一先由toHistogramIntegerNano()把毫秒转为整数纳秒Math.max(1, Math.trunc(ms * 1000))src/histogram.ts再record()写入摘要输出时再统一/ 1000转回毫秒src/histogram.ts包括用histogram.percentile(x)计算各分位点runTime记录发生在任务完成回调处recordRunTime(performance.now() - taskInfo.started)src/index.tswaitTime记录发生在任务分发成功时recordWaitTime(now - task.created)src/index.ts对外暴露的histogram对象还带有resetRunTime()与resetWaitTime()两个重置方法src/index.ts。4.4 前置条件与开关默认开启recordTiming默认为true因此默认就会收集 run/wait 直方图若构造时传入recordTiming: falseThreadPool不创建直方图处理器src/index.ts此时histogram.runTime/histogram.waitTime为undefinedutilization恒为0见下文测试 test/histogram.test.ts 分别验证了默认收集、recordTiming: false时不收集、以及resetRunTime()/resetWaitTime()后均值/标准差变为NaN、max归零等行为此外还有workerHistogram选项默认false开启后每个 Worker 单独记录耗时直方图src/worker_pool/index.ts每个PiscinaWorker通过histogram属性暴露自己的摘要测试见 test/histogram.test.ts。4.5 快速上手示例import { Piscina } from piscina; const pool new Piscina({ filename: new URL(./worker.js, import.meta.url).href, }); await Promise.all([ pool.run({ a: 1, b: 2 }), pool.run({ a: 3, b: 4 }), pool.run({ a: 5, b: 6 }), ]); console.log(平均执行耗时:, pool.histogram.runTime.average, ms); console.log(P99 执行耗时:, pool.histogram.runTime.p99, ms); console.log(P99 排队等待:, pool.histogram.waitTime.p99, ms); console.log(标准差:, pool.histogram.runTime.stddev); // 观测结束后重置开启新一轮统计 pool.histogram.resetRunTime(); pool.histogram.resetWaitTime(); await pool.destroy();五、池利用率utilization5.1 定义与公式utilization只读0~1 的小数是某一时间点上已完成任务的近似总执行耗时与线程池理论总容量之比。文档给出的计算逻辑源码实现见 src/index.ts理论容量capacityduration池子已运行毫秒数×options.maxThreads。这代表了池子在此时间段内绝对理论上的最大聚合计算时间近似总执行耗时totalMeanRuntime 已完成任务的平均执行耗时 × 已完成任务总数近似表示池子实际“干活”的总时间利用率 近似总执行耗时 ÷ 理论容量。对应源码const capacity this.duration * this.#pool.options.maxThreads; const totalMeanRuntime (this.#pool.histogram.runTimeSummary.mean / 1000) * count; return totalMeanRuntime / capacity;5.2 边界行为与注意事项若recordTiming为false没有直方图或尚无任务完成count 0utilization返回0src/index.ts因为容量是按maxThreads计算的“绝对上限”而实际线程数通常在minThreads与maxThreads之间伸缩所以利用率在实际使用中几乎不可能达到 1测试 test/simple-test.test.ts 断言任务未运行时utilization 0跑完若干任务后0 utilization 1语义上这是一个“点值快照”point-in-time ratio适合做趋势采样而非精确计量。把utilization与duration组合成时间序列例如按秒采样可以画出池子的负载曲线辅助判断是否需要调整minThreads/maxThreads。5.3 使用场景容量规划长期utilization接近容量上限说明maxThreads可能成为瓶颈应考虑增大上限或拆分任务冷启动判断池子刚创建时duration小、任务少utilization会偏低可据此判断池子是否已进入稳定工作状态与queueSize交叉分析utilization高 queueSize持续增长说明“线程不够用”utilization低 queueSize高说明任务分发或单个 Worker 处理存在异常。六、属性总览与监控实践6.1 快速参考表属性类型含义典型用途completednumber已完成任务累计数吞吐量统计durationnumberms实例已运行时长容量计算、稳定性判断optionsobject归一化后的生效配置运行时检查配置runTimehistogram summary任务执行耗时分布定位慢任务、长尾分析waitTimehistogram summary任务排队等待耗时分布定位调度/容量瓶颈threadsWorker[]池中全部 Worker 实例原生 Worker 操作idleThreadsnumber空闲ready 且空闲Worker 数判断剩余计算力queueSizenumber排队中任务数队列压力监控needsDrainboolean是否已满、需要排空背压信号utilizationnumber0~1池利用率快照容量规划、负载曲线6.2 一个完整的监控片段import { Piscina } from piscina; const pool new Piscina({ filename: new URL(./worker.js, import.meta.url).href, maxThreads: 8, maxQueue: auto, }); // 背压满了先停手排空再继续 pool.on(needsDrain, () console.log(队列已满暂停提交)); pool.on(drain, () console.log(队列已清空可以继续)); setInterval(() { console.log({ completed: pool.completed, idleThreads: pool.idleThreads, queueSize: pool.queueSize, needsDrain: pool.needsDrain, utilization: pool.utilization, runTimeP99: pool.histogram.runTime.p99, waitTimeP99: pool.histogram.waitTime.p99, }); }, 1000).unref();这个片段同时演示了本文涉及的绝大多数属性状态类completed、duration、队列类queueSize、needsDrain、idleThreads、直方图类runTime、waitTime与比率类utilization。将它们组合成一个心跳探针即可对生产环境中的 Piscina 线程池做低成本、可观测的持续监控。结语Piscina 的只读属性虽然简单却是线程池可观测性的全部入口completed/duration提供时间与数量维度threads/idleThreads/queueSize提供资源与队列维度runTime/waitTime提供延迟分布维度needsDrain提供背压控制信号utilization则把前几者浓缩为一个 0~1 的利用率快照。理解它们的实现位置src/index.ts、src/histogram.ts、src/worker_pool与测试行为test/simple-test.test.ts、test/histogram.test.ts、test/thread-count.test.ts、test/task-queue.test.ts你就能在真实负载下做出有理有据的容量决策。赞分享并发编程【免费下载链接】piscinaA fast, efficient Node.js Worker Thread Pool implementation项目地址https://gitcode.com/gh_mirrors/pi/piscina点击查看免费下载相关推荐Piscina 核心类完全指南new Piscina() 构造函数选项、直方图统计与自定义负载均衡Piscina 核心类完全指南new Piscina 构造函数选项、直方图统计与自定义负载均衡 导读 Piscina 是 Node.js 生态中一个基于 Wo并发编程Piscina API 全景指南Worker 线程池的类、方法、事件与属性详解Piscina API 全景指南Worker 线程池的类、方法、事件与属性详解 导读 本文围绕 piscina 仓库官方 API 参考文档 docs/docs并发编程MXNet numpy 统计例程Statistics Routines全指南从最值、均值到相关性与直方图MXNet numpy 统计例程Statistics Routines全指南从最值、均值到相关性与直方图 导读 本文围绕 MXNet 的 NumPy 兼容人工智能深度学习机器学习上一篇cppcheck 的 deallocret 检查器捕获“释放后返回指针”的未定义行为下一篇Style: {style_name}创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/13 9:17:26 · 阅读 1.2k Piscina 实例属性完全指南：从 completed、queueSize 到 utilization 与 runTime 直方图
并发编程【免费下载链接】piscinaA fast, efficient Node.js Worker Thread Pool implementation项目地址https://gitcode.com/gh_mirrors/pi/piscina点击查看免费下载导读Piscina 是一个基于 Node.js Worker Threads 的高性能线程池实现。本文聚焦于Piscina类暴露的全部只读实例属性逐一说明其语义、取值来源、在源码中的实现位置以及真实使用场景。读完本文你将掌握如何用completed、duration、queueSize、idleThreads监控池的健康状态如何用runTime、waitTime直方图定位性能瓶颈如何用needsDrain配合drain/needsDrain事件实现优雅的背压backpressure以及如何计算并解读utilization这一池利用率指标。本文所有属性均为只读readonly由实例内部状态派生调用方不能直接赋值。对应实现可查阅 src/index.ts 与 src/histogram.ts。一、基础状态属性completed、duration、options这三个属性回答的是最朴素的三个问题完成了多少任务池子运行了多久当前用的是什么配置1.1completed只读number当前已完成的任务总数是累计值只增不减。在源码中ThreadPool维护completed : number 0计数器src/index.ts每次任务回调执行时递增this.completedsrc/index.ts对外通过get completed ()直接暴露src/index.ts。无论任务成功还是失败只要被 Worker 处理并返回结果/错误都会计入completed。测试 test/post-task.test.ts 展示了任务完成后pool.completed变为1。典型用途与runTime.mean、utilization配合估算池子的吞吐总量。1.2duration只读number自该Piscina实例创建以来经过的毫秒数。实现非常直接src/index.tsget duration () : number { return performance.now() - this.#pool.start; }其中start在构造时由performance.now()记录src/index.ts。duration是utilization计算中的核心分母也是判断“池子冷启动后是否已经稳定运行”的简便依据。测试 test/simple-test.test.ts 断言运行若干任务后worker.duration 0。1.3options只读FilledOptions当前实例实际生效的配置副本。文档原话与传给构造函数的 options 对象具有完全相同的属性。要点源码佐证src/index.tsthis.options withNullPrototype({ ...kDefaultOptions, ...options, filename, maxQueue: 0, });默认值在kDefaultOptions中定义src/index.tsminThreads默认max(floor(cpuParallelism/2), 1)maxThreads默认cpuParallelism * 1.5maxQueue默认InfinityconcurrentTasksPerWorker默认1recordTiming默认truecloseTimeout默认30000构造时会做归一化maxQueue auto时被换算为maxThreads ** 2src/index.ts且minThreads/maxThreads相互钳制。因此读取options拿到的是归一化后的最终值例如auto已变成具体数字使用withNullPrototypesrc/common.ts创建一个无原型对象避免原型链污染。典型用途程序化地检查options.maxQueue、options.maxThreads是否满足当前负载预期文档也明确建议在配置maxQueue: auto后通过options.maxQueue查看换算结果docs/docs/api-reference/class.md。二、线程与队列视角threads、idleThreads、queueSize这三个属性描绘了线程池“有多少人在干活、多少人在排队”的动态画面。2.1threads只读Worker[]由线程池当前使用的Node.jsWorker实例数组来自node:worker_threads。实现直接遍历资源池中的WorkerInfo收集其底层workersrc/index.ts。数组元素是原生Worker可直接调用worker.threadId、worker.terminate()等原生 API。注意threads返回的是新数组每次 getter 调用都会重建不要依赖数组引用相等性判断变化应比较长度或元素。2.2idleThreads只读number当前已完成预热ready且没有在跑任何任务的 Worker 数量。实现细节src/index.tsget idleThreads () : number { let count 0; for (const workerInfo of this.#pool.workers.readyItems) { if (workerInfo.currentUsage() 0) count; } return count; }readyItems来自资源池AsynchronouslyCreatedResourcePoolsrc/worker_pool/base.tsWorker 完成启动预热后由pendingItems移入currentUsage()返回该 Worker 当前承接的任务数若正在运行带 abort 信号的任务则返回Infinitysrc/worker_pool/index.ts测试 test/thread-count.test.ts 完整演示了minThreads: 2时idleThreads在2 → 1 → 0 → 2之间的变化且destroy()后归零。典型用途判断池子是否还有空闲计算力避免盲目新增任务。2.3queueSize只读number当前等待分配给 Worker 的任务数即排队中的任务量。实现src/index.tsget queueSize () : number { const pool this.#pool; return Math.max((pool.taskQueue.size pool.skipQueue.length) - pool.pendingCapacity(), 0); }taskQueue是主任务队列skipQueue用于临时存放被跳过如等待 abort 信号处理的任务src/index.tspendingCapacity()是“正在启动中、尚未 ready 的 Worker 可承接的任务容量”src/index.ts从排队数中扣除因此队列越满、越接近maxQueuequeueSize越能真实反映排队压力结果是Math.max(..., 0)保证不会出现负值。测试 test/task-queue.test.ts 展示了maxThreads: 3时任务从直接分发到排队的临界行为当第 4 个任务提交时queueSize变为1。关键联动queueSize与drain/needsDrain事件直接相关——drain在queueSize归零时发出needsDrain在容量满载时发出docs/docs/api-reference/event.md。三、背压与容量needsDrain3.1 语义needsDrain只读boolean表示池子是否需要“排空”后才能继续处理新任务。文档定义当没有足够容量在不超出maxQueue或maxThreads的前提下处理更多任务时该值为true。其计算综合了线程数当前及待启动线程、maxQueue大小以及当前在途in-flight任务数。3.2 源码实现_needsDrain标志位在ThreadPool中维护对外由get needsDrain ()暴露src/index.ts。核心逻辑在_maybeDrain()src/index.tsif (maxCapacity currentUsage queueSize maxQueueSize) { this._needsDrain true; queueMicrotask(() this.publicInterface.emit(needsDrain)); }即当“所有 Worker 的在途任务数之和maxCapacity maxThreads * concurrentTasksPerWorker”与“队列长度”同时达到上限时置位并异步发出needsDrain事件当queueSize重新归零时复位并发出drain事件src/index.ts。3.3 使用要点与注意事项用途这是实现背压的“信号灯”。上游生产者看到pool.needsDrain true时应当暂停提交任务等待drain事件后再继续重要限制文档原注Piscina不会在maxQueue阈值之上缓冲任务所以needsDrain并不是“池子一定会接受更多任务”的保证。超过maxQueue的提交会直接以错误拒绝相关错误码见 docs/docs/api-reference/error-codes.mdPISCINA_ERR_TASK_QUEUE_LIMIT任务队列已达上限PISCINA_ERR_NO_TASK_QUEUE_AVAILABLE队列被禁用且所有 Worker 已满。测试 test/post-task.test.ts 验证了needsDrain事件触发时pool.needsDrain true且pool.queueSize 3maxQueue: 3。设计哲学_maybeDrain()的注释src/index.ts指出目标正是让使用者把“等待数”维持在 0——不给任务源提交永远无法立即执行的任务从而自然形成背压。这与 Node.js Writable stream 的drain行为对齐。四、性能观测runTime与waitTime直方图4.1 属性概览runTime与waitTime是直方图摘要对象histogram summary所有值单位均为毫秒runTime已完成任务的实际执行耗时分布waitTime任务在队列中等待被分配到 Worker 的耗时分布从任务创建taskInfo.created到分发开始taskInfo.started。两者结构完全一致均包含字段类型含义averagenumber所有任务的平均耗时与mean相同meannumber均值stddevnumber标准差反映耗时波动程度minnumber最快记录maxnumber最慢记录p{N}number百分位分布详见下文4.2 百分位字段p{N}的含义凡符合p{N}模式N 为数字如p1、p99的属性都代表耗时的百分位分布。文档示例p99表示 99% 的观测耗时都小于或等于该值。本实现提供的分位点src/histogram.ts为p0_001、p0_01、p0_1、p1、p2_5、p10、p25、p50中位数、p75、p90、p97_5、p99、p99_9、p99_99、p99_999尾部分位点p99.9以上特别适合发现“长尾慢任务”——平均值会被极端值拉高但p99_999能精确暴露偶发的尖峰延迟。文档中的典型输出示例运行耗时毫秒{ average: 1880.25, mean: 1880.25, stddev: 1.93, min: 1877, max: 1882.0190887451172, p0_001: 1877, p0_01: 1877, p0_1: 1877, p1: 1877, p2_5: 1877, p10: 1877, p25: 1877, p50: 1881, p75: 1881, p90: 1882, p97_5: 1882, p99: 1882, p99_9: 1882, p99_99: 1882, p99_999: 1882 }4.3 底层实现基于node:perf_hooks的直方图Piscina 使用 Node.js 内置的perf_hooks.createHistogram()RecordableHistogram作为底层数据结构src/histogram.tsPiscinaHistogramHandler内部维护#runTime与#waitTime两个直方图src/histogram.ts记录值统一先由toHistogramIntegerNano()把毫秒转为整数纳秒Math.max(1, Math.trunc(ms * 1000))src/histogram.ts再record()写入摘要输出时再统一/ 1000转回毫秒src/histogram.ts包括用histogram.percentile(x)计算各分位点runTime记录发生在任务完成回调处recordRunTime(performance.now() - taskInfo.started)src/index.tswaitTime记录发生在任务分发成功时recordWaitTime(now - task.created)src/index.ts对外暴露的histogram对象还带有resetRunTime()与resetWaitTime()两个重置方法src/index.ts。4.4 前置条件与开关默认开启recordTiming默认为true因此默认就会收集 run/wait 直方图若构造时传入recordTiming: falseThreadPool不创建直方图处理器src/index.ts此时histogram.runTime/histogram.waitTime为undefinedutilization恒为0见下文测试 test/histogram.test.ts 分别验证了默认收集、recordTiming: false时不收集、以及resetRunTime()/resetWaitTime()后均值/标准差变为NaN、max归零等行为此外还有workerHistogram选项默认false开启后每个 Worker 单独记录耗时直方图src/worker_pool/index.ts每个PiscinaWorker通过histogram属性暴露自己的摘要测试见 test/histogram.test.ts。4.5 快速上手示例import { Piscina } from piscina; const pool new Piscina({ filename: new URL(./worker.js, import.meta.url).href, }); await Promise.all([ pool.run({ a: 1, b: 2 }), pool.run({ a: 3, b: 4 }), pool.run({ a: 5, b: 6 }), ]); console.log(平均执行耗时:, pool.histogram.runTime.average, ms); console.log(P99 执行耗时:, pool.histogram.runTime.p99, ms); console.log(P99 排队等待:, pool.histogram.waitTime.p99, ms); console.log(标准差:, pool.histogram.runTime.stddev); // 观测结束后重置开启新一轮统计 pool.histogram.resetRunTime(); pool.histogram.resetWaitTime(); await pool.destroy();五、池利用率utilization5.1 定义与公式utilization只读0~1 的小数是某一时间点上已完成任务的近似总执行耗时与线程池理论总容量之比。文档给出的计算逻辑源码实现见 src/index.ts理论容量capacityduration池子已运行毫秒数×options.maxThreads。这代表了池子在此时间段内绝对理论上的最大聚合计算时间近似总执行耗时totalMeanRuntime 已完成任务的平均执行耗时 × 已完成任务总数近似表示池子实际“干活”的总时间利用率 近似总执行耗时 ÷ 理论容量。对应源码const capacity this.duration * this.#pool.options.maxThreads; const totalMeanRuntime (this.#pool.histogram.runTimeSummary.mean / 1000) * count; return totalMeanRuntime / capacity;5.2 边界行为与注意事项若recordTiming为false没有直方图或尚无任务完成count 0utilization返回0src/index.ts因为容量是按maxThreads计算的“绝对上限”而实际线程数通常在minThreads与maxThreads之间伸缩所以利用率在实际使用中几乎不可能达到 1测试 test/simple-test.test.ts 断言任务未运行时utilization 0跑完若干任务后0 utilization 1语义上这是一个“点值快照”point-in-time ratio适合做趋势采样而非精确计量。把utilization与duration组合成时间序列例如按秒采样可以画出池子的负载曲线辅助判断是否需要调整minThreads/maxThreads。5.3 使用场景容量规划长期utilization接近容量上限说明maxThreads可能成为瓶颈应考虑增大上限或拆分任务冷启动判断池子刚创建时duration小、任务少utilization会偏低可据此判断池子是否已进入稳定工作状态与queueSize交叉分析utilization高 queueSize持续增长说明“线程不够用”utilization低 queueSize高说明任务分发或单个 Worker 处理存在异常。六、属性总览与监控实践6.1 快速参考表属性类型含义典型用途completednumber已完成任务累计数吞吐量统计durationnumberms实例已运行时长容量计算、稳定性判断optionsobject归一化后的生效配置运行时检查配置runTimehistogram summary任务执行耗时分布定位慢任务、长尾分析waitTimehistogram summary任务排队等待耗时分布定位调度/容量瓶颈threadsWorker[]池中全部 Worker 实例原生 Worker 操作idleThreadsnumber空闲ready 且空闲Worker 数判断剩余计算力queueSizenumber排队中任务数队列压力监控needsDrainboolean是否已满、需要排空背压信号utilizationnumber0~1池利用率快照容量规划、负载曲线6.2 一个完整的监控片段import { Piscina } from piscina; const pool new Piscina({ filename: new URL(./worker.js, import.meta.url).href, maxThreads: 8, maxQueue: auto, }); // 背压满了先停手排空再继续 pool.on(needsDrain, () console.log(队列已满暂停提交)); pool.on(drain, () console.log(队列已清空可以继续)); setInterval(() { console.log({ completed: pool.completed, idleThreads: pool.idleThreads, queueSize: pool.queueSize, needsDrain: pool.needsDrain, utilization: pool.utilization, runTimeP99: pool.histogram.runTime.p99, waitTimeP99: pool.histogram.waitTime.p99, }); }, 1000).unref();这个片段同时演示了本文涉及的绝大多数属性状态类completed、duration、队列类queueSize、needsDrain、idleThreads、直方图类runTime、waitTime与比率类utilization。将它们组合成一个心跳探针即可对生产环境中的 Piscina 线程池做低成本、可观测的持续监控。结语Piscina 的只读属性虽然简单却是线程池可观测性的全部入口completed/duration提供时间与数量维度threads/idleThreads/queueSize提供资源与队列维度runTime/waitTime提供延迟分布维度needsDrain提供背压控制信号utilization则把前几者浓缩为一个 0~1 的利用率快照。理解它们的实现位置src/index.ts、src/histogram.ts、src/worker_pool与测试行为test/simple-test.test.ts、test/histogram.test.ts、test/thread-count.test.ts、test/task-queue.test.ts你就能在真实负载下做出有理有据的容量决策。赞分享并发编程【免费下载链接】piscinaA fast, efficient Node.js Worker Thread Pool implementation项目地址https://gitcode.com/gh_mirrors/pi/piscina点击查看免费下载相关推荐Piscina 核心类完全指南new Piscina() 构造函数选项、直方图统计与自定义负载均衡Piscina 核心类完全指南new Piscina 构造函数选项、直方图统计与自定义负载均衡 导读 Piscina 是 Node.js 生态中一个基于 Wo并发编程Piscina API 全景指南Worker 线程池的类、方法、事件与属性详解Piscina API 全景指南Worker 线程池的类、方法、事件与属性详解 导读 本文围绕 piscina 仓库官方 API 参考文档 docs/docs并发编程MXNet numpy 统计例程Statistics Routines全指南从最值、均值到相关性与直方图MXNet numpy 统计例程Statistics Routines全指南从最值、均值到相关性与直方图 导读 本文围绕 MXNet 的 NumPy 兼容人工智能深度学习机器学习上一篇cppcheck 的 deallocret 检查器捕获“释放后返回指针”的未定义行为下一篇Style: {style_name}创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考