为什么 Thread.Abort 仅在 isBackground 属性设置为 true 时才有效？

Question

我正在开发一个微型 UDP 控制台来发送一些数据来测试一些 GPRS 设备，所以我修改了我在 CodeProject 中找到的一个示例，它使用一个线程；但是当我想退出应用程序时遇到问题，即使我做了类似的事情，tread 也拒绝停止

If UdpOpen Then
   ThreadReceive.Abort()
   Me.Dispose()
   UdpOpen = False
End If

它停在第一行代码

Private Sub UdpReceive()
    Dim receiveBytes As [Byte]() = receivingUdpClient.Receive(RemoteIpEndPoint) '<--Halt here
    IpRemote(RemoteIpEndPoint.Address.ToString)
    Dim BitDet As BitArray
    BitDet = New BitArray(receiveBytes)
    Dim strReturnData As String = System.Text.Encoding.ASCII.GetString(receiveBytes)
    If UdpOpen Then
        StartUdpReceiveThread(CInt(RemotePortLbl.Text))
    End If

    PrintLog(strReturnData)
End Sub

所以我做了一些研究，通常在这个网页中找到了解决方案 Stop a thread that prevents program to close?

而且，正如第一条评论所说，我将 isBackground 属性设为 True 并且它可以工作，现在的问题是为什么？

是否有人更深入地了解它的工作原理？

Answer 1

.NET 内置了对异步接收 UDP 的支持。看到这个：

• UdpClient.BeginReceive

所以在这种情况下你不需要使用线程。

Answer 2

只有当 CLR 知道这样做是安全的时，线程才可中止。当线程深埋在操作系统调用中时，情况就不会如此。这从根本上说是不安全的，因为 CLR 无法知道线程是否获得了任何需要再次释放的内部操作系统锁。

通过将 IsBackground 属性设置为 true，您可以告诉 CLR 可以不中止线程，但将其留给操作系统进行清理-up 任何需要发布的东西。任何被占用的锁都不会再导致任何问题，因为任何可能死锁的代码都无法再运行。操作系统负责释放套接字使用的操作系统资源。就像您的程序因任何其他原因中止（例如您使用任务管理器终止它）一样。

正确的方法是调用套接字的 Dispose() 方法。这会在操作系统调用时拉下地板垫，它将停止等待接收任何内容，因为套接字是一只死鹦鹉。 Receive() 调用将完成一个 ObjectDisposedException，准备好捕获它。

另一个非常常见的场景是根本不使用线程，而是使用 BeginReceive()。清理的工作方式大致相同，当您调用 Dispose() 时，回调将运行。当您调用 EndReceive() 时，您会得到 ObjectDisposedException。同样，准备好抓住它并迅速离开，而不用对套接字做任何其他事情。

使用 Thread.IsBackground 是处理关机的一种非常合理的方式，假设您不必做任何复杂的事情来告诉线路另一端的程序您停止侦听消息。