Java线程优先级基本无效，因Linux CFS忽略用户态优先级、Windows JVM常归一化；应通过线程池隔离高低优任务；CPU密集型线程数宜设为availableProcessors()或+1，混合型按阻塞系数估算；禁用newCachedThreadPool()；onSpinWait()仅适用于纳秒级忙等。
Java线程优先级对实际调度基本没用
绝大多数情况下，Thread.setPriority() 不会影响线程执行顺序或抢占行为。JVM 将 Java 优先级映射到操作系统线程优先级，但 Linux 默认采用 CFS 调度器，忽略用户态优先级；Windows 虽支持，但 JVM 实现常做归一化处理，导致所有 Java 线程最终落在同一 OS 优先级区间。
- 不要用
setPriority(Thread.MAX_PRIORITY)去“加速”关键任务——它既不保证更快执行，也不提升 CPU 时间片配额 - 若真需区分响应性，应通过线程池隔离：高优任务走专用
ThreadPoolExecutor（如固定大小 + 无界队列），低优任务走另一组线程池并限制其最大并发数 - 唯一可能生效的场景是：在嵌入式实时 JVM（如 Jamaica VM）中启用 RTSJ 支持，但这已超出标准 JDK 范围
线程数 ≠ 并发吞吐量，CPU 密集型任务建议用 Runtime.getRuntime().availableProcessors()
盲目增加线程数只会加剧上下文切换开销，尤其当任务主要是计算而非 I/O。一个满载的 8 核机器，跑 64 个 CPU 密集型线程，实际吞吐往往低于 12 个线程。
- 纯计算任务（如图像压缩、数值模拟）：线程池核心线程数设为
availableProcessors()或availableProcessors() + 1即可 - 混合型任务（含数据库查询、HTTP 调用）：按阻塞系数估算 —— 若平均每个任务 20% 时间在计算、80% 在等待，则理论最优线程数 ≈
availableProcessors() / 0.2 - 避免使用
Executors.newCachedThreadPool()：它不限制最大线程数，突发请求可能瞬间创建数百线程，触发 OOM 或系统卡顿
用 Thread.onSpinWait() 替代空循环，但仅适用于极短等待（纳秒级）
Thread.onSpinWait() 是 JDK 9 引入的提示指令，告诉 CPU “当前线程正在忙等，别调度走”，可降低功耗并减少不必要的上下文切换。但它不是锁替代品，也不能替代 LockSupport.park() 或 Object.wait()。
while (!ready) {
Thread.onSpinWait(); // ✅ 合理：预期等待时间 < 100ns，且 ready 是 volatile 字段
}
// ❌ 错误：等待网络响应或数据库结果时调用 onSpinWait()，会白耗 CPU
- 只用于自旋锁、无锁数据结构内部的极短等待判断（如
AtomicIntegerCAS 失败后重试） - 必须配合
volatile或原子变量读取，否则编译器/JIT 可能优化掉轮询逻辑 - 在 ARM64 或某些旧 x86 CPU 上，该方法可能被忽略，行为退化为空操作
线程绑定 CPU 核心（affinity）在 Java 中不可靠，别硬搞
虽然 Linux 有 taskset、JVM 有 -XX:+UseThreadPriorities 等参数，但标准 JDK **不提供 API 让 Java 线程绑定到特定 CPU 核心**。第三方库（如 java-thread-affinity）依赖 JNI 和 /proc 接口，存在严重兼容风险：
立即学习“Java免费学习笔记（深入）”；
- Docker/Kubernetes 环境下，cgroups 限制会使绑定失效，甚至导致线程无法启动
- JDK 升级（尤其是从 8 到 17+）可能破坏底层系统调用假设
- GC 线程、JIT 编译线程、Finalizer 线程等仍由 JVM 自主调度，无法统一绑定
真正可控的资源隔离方式是：用独立进程 + cgroups v2 或 systemd.slice 限制 CPU 配额，再让每个进程内运行合理数量的 Java 线程。
