Java Socket粘包不是Bug，而是TCP字节流协议的正常现象，因TCP不保证消息边界，需应用层通过定长、分隔符或长度前缀等方案解决。
为什么Java Socket会粘包？不是Bug，是TCP的“正常操作”
TCP是字节流协议，不保证“你write一次，对方read一次就刚好拿到一整条消息”。它只管把字节可靠地送到，至于怎么切、怎么合，全由底层优化策略（比如Nagle算法）和网络状况决定。常见现象包括：read()一次拿到两条消息拼在一起（粘包），或一条消息被拆成两次read()返回（半包）。这不是Java的问题，也不是Socket写错了——是所有基于TCP的应用层协议都必须面对的边界问题。
定长协议：简单但容易踩内存和性能坑
适用于日志上报、传感器心跳等长度严格可控的场景，比如每条指令固定200字节。
- write()前必须用Arrays.fill()补零或空格填满，否则接收方按固定长度截取会混入脏数据
- 接收端ByteBuffer.allocate(200)后必须调用buffer.flip()再读，否则get()可能越界或读不到内容
- 消息实际长度远小于200时，大量0x00白白占带宽，对高并发小消息场景很不友好
- 一旦某条消息超长（比如201字节），整个协议就崩了——要么截断，要么污染下一条
分隔符法：换行符最常用，但别让业务数据“撞车”
用\n或|做消息边界，适合文本协议（如HTTP头、自定义命令行协议）。
- 必须确保业务数据里**绝对不出现**该分隔符，否则BufferedReader.readLine()会提前截断
- 如果用InputStreamReader配合readLine()，记得服务端发送时也得加\n，且注意不同系统换行符差异（\r\n vs \n）
- 不适合二进制数据，因为\n可能天然存在于图片、音频字节流中
- 遇到超长消息（比如几MB日志块），readLine()可能因缓冲区溢出抛OutOfMemoryError长度前缀法：生产环境首选，但readInt()不能裸用
在每条消息前写4字节int表示后续数据长度，接收方先读长度、再循环读够对应字节数。这是最通用可靠的方案。
- 发送端必须用DataOutputStream.writeInt()，接收端用DataInputStream.readInt()，避免大小端错乱
- readInt()可能阻塞，但更危险的是read(byte[])只返回部分字节——必须用readFully()或手动while循环校验已读字节数
- 长度字段本身也要防异常：如果读到负数或超大值（比如2GB），应立即关闭连接，防止被恶意构造包耗尽内存
- 实际项目中建议把长度字段升级为变长编码（如varint），节省1~3字节开销，尤其适合短消息高频场景
-
write()前必须用Arrays.fill()补零或空格填满，否则接收方按固定长度截取会混入脏数据- 接收端
ByteBuffer.allocate(200)后必须调用buffer.flip()再读，否则get()可能越界或读不到内容- 消息实际长度远小于200时，大量
0x00白白占带宽，对高并发小消息场景很不友好- 一旦某条消息超长（比如201字节），整个协议就崩了——要么截断，要么污染下一条
分隔符法：换行符最常用，但别让业务数据“撞车”
用\n或|做消息边界，适合文本协议（如HTTP头、自定义命令行协议）。
- 必须确保业务数据里**绝对不出现**该分隔符，否则BufferedReader.readLine()会提前截断
- 如果用InputStreamReader配合readLine()，记得服务端发送时也得加\n，且注意不同系统换行符差异（\r\n vs \n）
- 不适合二进制数据，因为\n可能天然存在于图片、音频字节流中
- 遇到超长消息（比如几MB日志块），readLine()可能因缓冲区溢出抛OutOfMemoryError长度前缀法：生产环境首选，但readInt()不能裸用
在每条消息前写4字节int表示后续数据长度，接收方先读长度、再循环读够对应字节数。这是最通用可靠的方案。
- 发送端必须用DataOutputStream.writeInt()，接收端用DataInputStream.readInt()，避免大小端错乱
- readInt()可能阻塞，但更危险的是read(byte[])只返回部分字节——必须用readFully()或手动while循环校验已读字节数
- 长度字段本身也要防异常：如果读到负数或超大值（比如2GB），应立即关闭连接，防止被恶意构造包耗尽内存
- 实际项目中建议把长度字段升级为变长编码（如varint），节省1~3字节开销，尤其适合短消息高频场景
readInt()不能裸用
在每条消息前写4字节int表示后续数据长度，接收方先读长度、再循环读够对应字节数。这是最通用可靠的方案。- 发送端必须用
DataOutputStream.writeInt()，接收端用DataInputStream.readInt()，避免大小端错乱-
readInt()可能阻塞，但更危险的是read(byte[])只返回部分字节——必须用readFully()或手动while循环校验已读字节数- 长度字段本身也要防异常：如果读到负数或超大值（比如2GB），应立即关闭连接，防止被恶意构造包耗尽内存
- 实际项目中建议把长度字段升级为变长编码（如varint），节省1~3字节开销，尤其适合短消息高频场景
粘包问题本身不难，难的是在“能跑通”和“能扛住线上流量+异常输入”之间那层薄薄的校验逻辑。很多人卡在read()返回值没判断、长度头没校验、或者忘了readFully()的语义——这些地方一漏，上线后就是偶发解析失败，查起来特别费劲。
