被阻止的Android线程何时真正被杀死？

我正在与安卓系统中已知的错误作斗争，即一个被阻止的USB读取线程无法被解锁。没有任何东西能阻止它；不象套接字那样关闭底层对象，不使用NIO并调用FileChannel.close（它向被阻止的线程发送异常），什么都没有。所以我一直在设计一些解决办法来容忍Android中的这个bug

最大的问题是，由于线程不会消亡，因此它保留了对底层FileInputStream对象或FileChannel对象的引用，或者您正在使用的任何对象的引用。由于该对象仍然存在，因此无法与连接的USB设备重新关联。您得到了众所周知的无法打开/dev/usb_附件的绝望消息

所以。。。由于线程不能在外部终止或中断，而且它不会自己醒来释放对象，我想知道这样一个被阻塞的线程及其相关资源何时会被操作系统清除。在大多数操作系统中，线程将是整个进程的一部分，当该进程终止时，所有线程和对象将同时被清除，从而最终释放USB连接，以便其他东西可以与之关联。但实验表明，线程或对象可能会超出进程。我不知道如何以及在什么情况下，但到目前为止，我仍然收到无法打开/dev/usb_附件消息，即使在上一个进程已终止之后

所以。。。最后是什么清理与进程相关的所有内容，包括其所有线程和实例对象？我该如何清理历史记录，使新流程有机会与/dev/usb_附件关联

---

谢谢

为什么USB线程会被阻塞？缓冲区是否足够大以存储所有USB数据包数据？当连接的USB设备没有可用数据时，fileInputStream.read上的专用读取线程会阻塞。当接收到某些数据时，它将取消阻止。但是，如果Android应用程序正在终止，则无法解除阻止.read，因此另一个应用程序或终止应用程序的新实例无法与USB设备关联，因为Android仍然有一个针对它的开放对象。我强烈希望能够干净地解除线程阻塞并正式关闭FileInputStream对象，但这是Android中的一个已知错误，因此我必须解决它。