Java中处理Socket异常保障程序持续运行及IO流选型建议

问题描述 #

开发Skribbl克隆版时，采用JavaFX结合Socket编程，通过TCP连接使用ObjectInputStream和ObjectOutputStream传输数据。但运行时出现间歇性异常：每5次运行约2次无异常，其余情况会触发大量Socket相关异常，诱因难以定位。

遇到的具体异常如下：

1. Connection Reset异常 #

java.net.SocketException: Connection reset
    at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
    at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
    at java.base/java.io.BufferedInputStream.fill(BufferedInputStream.java:252)
    at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:271)
    at java.base/java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2854)
    at java.base/java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:3181)
    at java.base/java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:3191)
    at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1621)
    at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:488)
    at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:446)
    at com.nttd.wtdoodle.Client.Game.Server.PlayerHandler$1.run(PlayerHandler.java:54)
    at java.base/java.lang.Thread.run(Thread.java:829)
        Error sending Message to client

2. StreamCorruptedException异常 #

java.io.StreamCorruptedException: invalid type code: 00
    at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1701)
    at java.base/java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2479)
    at java.base/java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2373)
    at java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2211)
    at java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1670)
    at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:488)
    at java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:446)
    at com.nttd.wtdoodle.Client.Game.Player.PtoSBridge$1.run(PtoSBridge.java:55)
    at java.base/java.lang.Thread.run(Thread.java:829)
        Error sending Message to client

此外还出现过ClassCastException，这类异常的间歇性特征增加了排查难度。

ObjectInputStream/ObjectOutputStream的适用性分析 #

ObjectInputStream和ObjectOutputStream理论上可用于TCP Socket通信，但它们的特性极易引发这类间歇性异常：

• 严格依赖序列化协议：对象的序列化与反序列化要求类结构、serialVersionUID、类加载器完全匹配，任何差异都会触发StreamCorruptedException或ClassCastException。
• 流状态高度敏感：Object流会维护内部序列化状态，若Socket连接出现半关闭、数据丢失（TCP虽保证有序，但异常断开重连会破坏流状态），会直接导致流结构损坏，引发Connection reset或流异常。
• 隐式缓冲与同步问题：Object流自带内部缓冲，多线程场景下若读写操作未正确同步，极易出现数据读取错位，进而触发无效类型码异常。

对于Skribbl这类实时多人协作应用，Object流的序列化开销和状态敏感性反而会成为隐患，频繁消息传输场景下，微小的同步问题就会引发间歇性故障。

替代方案验证 #

将ObjectInputStream/ObjectOutputStream替换为BufferedReader和BufferedWriter后，问题完全解决，原因在于：

• 文本字符流逻辑简单直观，无需处理复杂序列化协议，可通过JSON、自定义分隔符文本等格式传输结构化数据，可控性更强。
• 字符流的读写同步和错误处理更容易实现，大幅降低了流状态不一致的风险。
• Skribbl以文本指令、坐标数据等简单信息传输为主，文本流完全满足需求，且调试、维护成本更低。

总结 #

若应用以传输简单结构化数据（如指令、文本、基础数据类型）为主，优先选择BufferedReader/BufferedWriter、DataInputStream/DataOutputStream这类简单流，避免Object流带来的序列化复杂性和状态敏感问题。若需传输复杂对象，建议先将对象序列化为JSON、Protobuf等通用格式，再通过字符/字节流传输，比直接使用Object流更可靠。

内容的提问来源于stack exchange，提问作者Vinayak Kushwaha