TasksMax 是 systemd 对单个服务线程与进程总数的硬限制，默认 512，Java 应用启动时易超限导致“unable to create native thread”错误；需在 service 文件 [Service] 段设 TasksMax=infinity 或具体值如 4096，并 reload+restart 生效。
TasksMax 是什么，为什么 Java 服务常被它卡住
Java 应用（尤其是 Spring Boot、Nacos 客户端、Netty 服务）启动时会密集创建线程池、定时器、gRPC worker 等，TasksMax 就是 systemd 对单个服务能拥有的最大任务数（即线程 + 进程总数）的硬限制。默认值通常是 512，而一个中等规模的 Spring Boot 应用启动瞬间就可能突破 600+ 线程 —— 此时 pthread_create 失败，JVM 报 java.lang.OutOfMemoryError: unable to create native thread，但堆内存明明还有空余。这和 ulimit -u 不同：后者只管 fork 出的进程数，而 TasksMax 是 cgroup v2 的 pids.max 控制项，覆盖所有内核调度实体。
如何在 service 文件里正确设置 TasksMax
必须在 [Service] 段落中显式声明，不能靠全局配置覆盖（除非你真想改全系统）。常见错误是写成 TasksMax=unlimited 或 TasksMax=0，这两个值 systemd 都不认：
师生共创生态系统对接指南。当用户需要对接大学政策、平台资源、投资机构、产业伙伴等外部资源支持时使用。触发词：师生共创生态、大学支持、平台赋能、投资对接、产业合作、政策支持、清华x-lab、孵化器、创业资源
-
TasksMax=infinity是唯一合法的“不限制”写法（注意拼写，不是infinite） - 设具体数值如
TasksMax=4096更稳妥，便于监控和资源收敛 - 若服务使用
Type=forking，需确认主进程 PID 被正确识别，否则 systemd 可能统计错归属范围 - 修改后必须执行
systemctl daemon-reload和systemctl restart your-service，仅 reload 不生效
验证是否生效的三步检查法
别只信配置文件写了，得看运行时实际值：
- 查当前服务的实时限制：
systemctl show your-service | grep TasksMax，输出应为TasksMax=4096或TasksMax=infinity - 查运行中进程的 cgroup 限制：
cat /proc/$(systemctl show your-service -p MainPID --value)/cgroup找到 pids controller 路径，再读cat /sys/fs/cgroup/pids/.../pids.max - 观察线程数增长是否触顶：
systemctl status your-service里会显示类似Tasks: 382 (limit: 4096)的实时快照
容易被忽略的兼容性细节
某些旧版 systemd（v239 之前）不支持 TasksMax，会静默忽略该配置。如果 systemctl show 查不到该字段，先运行 systemd --version。CentOS 7 默认 systemd 版本是 v219，必须升级或改用 DefaultTasksMax 放在 /etc/systemd/system.conf 中 —— 但这会影响所有服务，不够精准。另外，OpenJDK 本身不感知 TasksMax，它只依赖内核返回的 errno=ENOSPC，所以 JVM 参数如 -XX:ActiveProcessorCount 无法绕过这个限制。
