Java进程间通信不必依赖Socket，可根据需求选择共享内存（MappedByteBuffer+文件锁）、Unix域套接字（JNR-Posix）或嵌入式消息库（ZeroMQ ipc://），各方案在性能、安全、跨平台性上权衡取舍。
Java进程间通信不一定要用Socket
Java应用需要跨进程交换数据时，Socket确实常见，但不是唯一解，更不是最轻量或最安全的选择。是否该用它，取决于你的真实需求：是需要跨机器、跨语言、还是仅限本机不同JVM之间？选错方案会带来连接管理复杂、序列化漏洞、防火墙阻断或调试困难等问题。
共享内存方案：MappedByteBuffer + 文件锁
适用于同一台机器上多个Java进程高频读写少量结构化数据（如配置热更新、状态快照）。比Socket延迟低、无网络栈开销，但需自行处理并发和可见性。
-
MappedByteBuffer映射一个临时文件到内存，多个进程可同时映射同一文件路径 - 必须用
FileChannel.lock()控制写入互斥，否则数据会错乱；lock()在Windows下可能阻塞整个文件，Linux更可靠 - 写入后需调用
buffer.force()确保落盘，否则另一进程可能读到旧值 - 不能传递对象引用，只适合基本类型或固定格式字节布局（比如用
putInt()/getInt()手动编解码）
示例关键片段：
FileChannel channel = FileChannel.open(Paths.get("/tmp/shared.buf"), READ, WRITE);<br>MappedByteBuffer buffer = channel.map(READ_WRITE, 0, 4096);<br>buffer.putInt(0, 123); // 写入int到偏移0<br>buffer.force(); // 强制刷盘
本地IPC方案：Unix Domain Socket（通过JNR-Posix）
比TCP Socket快、不走网络协议栈、支持文件系统级权限控制，适合Linux/macOS本机多进程通信，且天然兼容C服务。Java标准库不支持，需借助JNI封装。
立即学习“Java免费学习笔记（深入）”；
- 用
jnr-posix库可直接创建AF_UNIXsocket，路径为文件系统路径（如/tmp/myapp.sock），不占用端口 - 连接失败时常见错误是
java.io.IOException: No such file or directory，通常因socket文件被删或权限不足（检查ls -l /tmp/myapp.sock） - 服务端必须先绑定路径并
listen()，客户端才能connect()；路径长度受OS限制（Linux一般sizeof(struct sockaddr_un.sun_path)≤ 108） - 不支持Windows原生，Windows上得退回到NamedPipe或改用TCP loopback
消息总线替代方案：嵌入式ZeroMQ或NanoMSG
当需要解耦、广播、负载均衡或多语言互通时，硬写Socket容易陷入粘包、重连、心跳、序列化绑定等陷阱。嵌入式消息库能绕过JVM网络层，用本地IPC（如inproc://或ipc://）实现零拷贝通信。
-
zmq_ctx_new()创建上下文后，用ipc://协议（Linux/macOS）或inproc://（同进程内线程间）通信，避免TCP握手和内核缓冲区拷贝 - Java绑定（如
jeromq）默认使用tcp://，必须显式指定ipc:///tmp/zmq.ipc才启用本地域套接字 -
ipc://路径必须是绝对路径，且目录需存在、有写权限；删除IPC文件不会自动清理已建立的连接，需手动unlink() - ZeroMQ不保证消息顺序和送达，若需严格有序+持久化，反而不如直接用RabbitMQ或Kafka嵌入式模式
真正麻烦的从来不是“怎么通”，而是“通了之后谁负责清理资源、谁定义消息边界、谁处理对方崩溃”。Unix Domain Socket的路径残留、MappedByteBuffer的缓存可见性、ZeroMQ的上下文生命周期——这些细节一旦漏掉，问题会在压测或升级后才爆发。
