线程池不支持原生权重分配，需在任务提交、执行上下文和资源管控三层叠加策略：权重绑定租户/任务流，用加权轮询或优先级队列调度；用ScopedValue实现上下文隔离；通过cgroup、内存/连接数配额实现硬隔离；线程池需配合有限队列与租户感知拒绝策略。
线程池本身不直接支持“基于权重的并发资源分配与隔离”，它只负责复用线程、控制最大并发数和队列行为。要实现带权重的资源分配与隔离，必须在任务提交层、执行上下文层和资源管控层叠加策略，而非依赖线程池原生能力。
一、明确权重作用对象：不是线程，而是租户/任务流
权重不能施加于线程或线程池大小，而应绑定到任务源头——例如租户ID、API路由、服务等级（SLA tier）或请求类型（如实时查询 vs 批量导出）。关键逻辑是：同一租户的任务应尽可能复用上下文、受统一配额约束，并在竞争时获得与其权重匹配的调度倾斜。
- 为每个租户维护独立的轻量级任务队列（非阻塞队列），队列消费速率按权重比例动态调节
- 使用带权重的轮询（Weighted Round Robin）或优先级队列（PriorityQueue
）分发任务到共享线程池 - 避免为每个租户创建专属线程池——会造成线程膨胀、内存开销高、JVM GC压力大
二、执行上下文隔离：确保变量不跨租户泄漏
长连接场景下，用户会话、认证信息、租户配置等需全程透传。Java中不能仅靠ThreadLocal，因为虚拟线程（Virtual Thread）切换时ThreadLocal不会自动继承；必须升级为ScopedValue（JDK 21+）或配合显式上下文封装。
- 定义租户上下文容器：ScopedValue
TENANT_ID = ScopedValue.newInstance() - 在接收请求时绑定：ScopedValue.where(TENANT_ID, "tenant-a").run(() -> submitToThreadPool(task))
- 业务代码中直接获取：TENANT_ID.get()，无需手动传递参数
- 数据库连接、日志MDC、指标标签均基于该值自动打标，实现可归因的监控与限流
三、资源使用硬隔离：CPU、内存、连接数按权重配额
权重最终要落地为可观测、可限制的资源边界，否则只是调度幻觉。需结合操作系统级机制与应用层拦截：
- CPU时间：通过cgroup v2为不同租户进程组设置cpu.weight（1–10000），与线程池调度权重联动
- 堆外内存与连接数：在任务执行前校验租户当前内存占用（如Netty PooledByteBufAllocator统计）和活跃连接数，超限则拒绝或降级
- 长连接保活心跳、读写超时、最大消息长度等参数，全部按租户维度配置并热加载
- 示例：租户A权重800，租户B权重200 → 其对应cgroup cpu.weight设为800和200，同时连接数上限设为80和20
四、线程池配合策略：有限队列 + 拒绝策略定制
选用ThreadPoolExecutor，但关键配置需适配权重模型：
- corePoolSize设为合理最小值（如CPU核心数），避免空闲线程浪费；maxPoolSize可略高，但需配合RejectedExecutionHandler做租户感知拒绝
- 使用SynchronousQueue或小容量LinkedBlockingQueue，防止低权任务积压阻塞高权任务
- 自定义拒绝策略：new TenantAwareRejectedHandler()，记录租户ID、任务类型、队列水位，触发告警或自动扩容
- 启用allowCoreThreadTimeOut(true)，保障低峰期资源回收
