bootstrap.memory_lock设为true不一定生效，因需系统级权限支持：Linux要求进程RLIMIT_MEMLOCK≥JVM堆大小，Docker需--ulimit memlock=-1:-1，systemd需单独配置LimitMEMLOCK，且内核须具备cap_ipc_lock能力，否则mlockall调用失败导致内存仍可被swap。
bootstrap.memory_lock 设为 true 为什么不一定生效
设了 bootstrap.memory_lock: true 却看到日志里报 Unable to lock JVM Memory，或者 GET _nodes?filter_path=**.mlockall 返回 "mlockall": false，说明锁内存失败。这不是配置写错了，而是系统层面没放行。
- Linux 要求进程有
RLIMIT_MEMLOCK权限，且值必须 ≥ JVM 堆大小（比如 -Xms4g -Xmx4g 就至少要 4G） - Docker 容器默认禁用
memlock，需显式加--ulimit memlock=-1:-1 - systemd 启动时，
LimitMEMLOCK可能被覆盖，得在 service 文件里单独配 - 如果系统总内存紧张，
mlockall可能直接让 JVM 启动失败（不是报错，是静默退出）
验证 mlockall 是否真正生效的命令
别只看配置文件，得查运行时状态：
- 启动后立刻执行：
curl -s 'localhost:9200/_nodes?filter_path=**.mlockall' | grep -o '"mlockall":true'—— 必须返回匹配内容才算成功 - 查系统级限制：
prlimit -n $(pgrep -f "elasticsearch.*-Des.path.conf") | grep memlock，确认 soft/hard 都 ≥ JVM 堆上限 - 查内核是否允许：
cat /proc/$(pgrep -f "elasticsearch.*-Des.path.conf")/status | grep CapEff，确保有cap_ipc_lock能力（尤其容器环境）
不改系统权限时的替代方案：降低 swap 倾向
如果无法调整 memlock（比如共享宿主机、权限受限），至少得压住 swap 触发概率：
- 临时关闭所有 swap：
swapoff -a（重启失效） - 永久降低倾向：在
/etc/sysctl.conf加vm.swappiness=1，再执行sysctl -p - 注意：swappiness=0 不等于禁用 swap，只是“尽可能不 swap”，某些内核版本下仍可能触发；而
swapoff -a才是真禁用 - 配合检查：
free -h看 Swap 行是否全为 0，cat /proc/sys/vm/swappiness确认值已加载
Docker 环境下 bootstrap.memory_lock 的典型陷阱
Docker 默认禁止锁定内存，即使你在 elasticsearch.yml 里写了 true，也大概率失败：
- 必须加启动参数：
--ulimit memlock=-1:-1（不能只写 soft 或 hard） - 镜像若基于 Alpine，musl libc 对
mlockall支持不稳定，建议换用 Debian/Ubuntu 基础镜像 - 使用
docker-compose.yml时，ulimits 要写在服务同级，不是 environment 下：services: es: ulimits: memlock: soft: -1 hard: -1 - Pod 中用 Kubernetes 时，对应字段是
securityContext: { privileged: false, capabilities: { add: ["IPC_LOCK"] } }，光靠ulimits不够
mlockall 的许可边界——哪怕只差 1KB 的 memlock 限额，ES 就会安静地放弃锁内存，然后继续跑，直到某次 GC 把节点拖垮。 
