C# 串口通讯之艰难排错之路 —— system.ObjectDisposedException已关闭 Safe handle

今天写了一个串口通讯扫码枪驱动，程序运行后，不出意外的全线崩溃，开始了漫长的排查之旅，具体情况报错如下：

复制代码

解决未处理 System.ObjectDisposedException
Message=已关闭 Safe handle
Source=mscorlib
ObjectName=""
StackTrace:
在 System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
在 System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
在 Microsoft.Win32.UnsafeNativeMethods.GetOverlappedResult(SafeFileHandle hFile, NativeOverlapped* lpOverlapped, Int32& lpNumberOfBytesTransferred, Boolean bWait)
在 System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()
在 System.Threading.ThreadHelper.ThreadStart_Context(Object state)
在 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
在 System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
在 System.Threading.ThreadHelper.ThreadStart()

真的真的很无语，程序正常跑了一会，也能捉到数据，突然它就中风了，数据捉不到了，也没有任何报错。

逼不得已程序重新解包重装，到处打断点一步一步调试。最后发现当这个BUG出现时，程序直接崩溃，无法跟踪到错误代码位置。

最后意识到SerialPort类引起的问题，可能是在已释放的SerialPort对象上尝试进行操作导致的问题。

思路一：

为了解决这个问题，可以在使用完SerialPort对象后，确保正确地释放和关闭它。
但是呀，我的是扫码枪啊，串口必须一直打开，怎么可能关闭它，于是这个方案立马放弃。

思路二：

我在使用SerialPort的时候可以检查它的状态呀确保在处理数据之前，串口仍然处于打开状态。这样可以避免在已关闭的串口上进行操作，从而减少System.ObjectDisposedException异常的发生。
说干就干，代码增加一行 if 判断：

if (!serialPort.IsOpen)
{
serialPort.Open();
}

思路三：

在一个函数内利用SerialPort创建了串口通信实例后，没有将该实例放入任何其他容器中进行缓存，从而也会导致了上述崩溃BUG的产生。
那我就修改代码：将该实例放入了一个全局变量List<通信客户端>集合，下面的代码分别放到对应位置就行。

//这个作为全局变量就声明创建
public List PortModels = new List();

//这个在实例化对象后封装
PortModels.Add(SerialPort);/

哈哈哈，经过以上几步该BUG终于得以解决，家人们高歌万岁吧！！！