2 解决办法

　　2.1 查错

　　其实问题的解决还比较顺利。

　　通过查看程序的调用栈，发现程序出错前总是停留在发送Socket数据包的过程里。接着，进一步通过单步跟踪，发现在发送数据包的过程中，Socket检测到对端连接已经断开，就会触发OnDisconnect事件。而我正是在ServerSocket的OnDisconnect事件中根据传递进来的Socket句柄，找到对应的对象将之销毁的。

　　我在ServerSocket的OnDisconnect事件中的代码如下：

procedure Txxxx.ServerClientDisconnect(Sender: TObject;Socket: TCustomWinSocket);

Begin

…

FLines.DestroyLineBySocket(Socket);//正是这一句，在不合适的时机释放了对象

…

End;
　　问题是这么出现的。

　　比如，在某个过程中具有如下代码（前面为行号）：

　　1 FLine.DoSomething；

　　2 FLine.SendSocketData；

　　3 FLine.DoOtherThings；

　　其中，FLine是代表一路呼叫的对象。该对象内部引用了一个TCustomWinSocket指针。SendSocketData就是利用此Socket进行数据发送。

　　Flines是TLine对象的容器类的一个实例。

　　由此不难解读前述的各类错误：

　　1． 由于行2的Socket连接断开导致FLine对象释放，因此行3访问DoOtherThings几乎必然造成访问地址错；

　　2． 由于行2的对象销毁，因此程序中类似“Object as TLine”的代码导致第二类错误；

　　3． 由于对象提前销毁，善后处理工作未到位导致第三类错误；

　　2.2 解决方案

　　明白其原因后，问题解决起来就容易多了。

　　上述问题不外乎两个方案：

　　一， 判断实例是否存在

　　在DoOtherThings之后，判断FLine对象是否仍然处于Flines之中，若是则继续处理，否则结束处理；

　　二， 延迟销毁FLine对象

　　在ServerSocket的OnDisconnect中，将FLine对象抛入垃圾池，待时机成熟时再销毁。

　　考虑到方案一所要改动的代码量较大，同时，此种方案代码也不甚优美，因此决定采用方案二，即引入垃圾回收机制来解决问题。方案二的要点是选择合适的时机真正销毁对象。而对于这一点，问题倒不大，只需选择消息循环中处理消息的第一个环节进行回收即可。因为在之后的处理环节中，必然能够确保对FLine是否仍然有效的检查。