这个我有点不明白。在Java API中，有一些方法像 Thread.destroy() 完全没有实现的。(我知道它没有被实现可能是因为它容易产生死锁，但这不是我想说的。) 如果它没有实现，那为什么还要把它包含在公共API中呢？这只是一个无用的方法，人们可以在运行时调用它来引起异常。
当你在实现一个接口，而某个特定的实现由于某种原因没有实现所有的方法时，我可以看到这种事情的意义。但线程不是这种情况。
我唯一能想到的是，这是Java开发人员在早期采取的一个设计决定，目的是为了展示计划中的功能--显然随着线程问题的发现，它从来没有得到回报。但这只是一个大胆的猜测，而且似乎有点愚蠢。
有谁能对这个问题进行一些说明吗？
继而，既然没有实施，为什么不删除呢？我知道有Java向后兼容性的问题，但是既然没有任何代码可以调用这个方法并在运行时工作，那么它肯定不是一个代码破坏的变化？还是说，以前可以编译，现在不能编译也算（即使不能编译成任何有意义的东西？
编辑：从Java 11开始，它确实被删除了。
文档中的 线程.destroy() 链接到 废止的原因 的方法。奇怪的是，链接中写道："我们目前没有实现它，但也没有废弃它。
我们现在还没有实现它，但也没有废弃它。
即使该方法已被明确注释为过时。 就好像他们把它包含在API中一样，这样人们就可以调用它，并期望获得 设计 的功能，后来想了想，他们就在文档中加入了 "未实现，但未废弃 "的说明，然后就直接废弃了它，忘了更新文档。
甲骨文确实采取了 错误报告也许这符合他们可以用来改进他们的文档的反馈。
你有没有读过 文献 为它？
这种方法本来就是为了在不清理的情况下销毁这个线程。它所拥有的任何监视器都将保持锁定。然而，这个方法从未被实现。如果要实现的话，它将会像suspend()一样容易产生死锁。如果目标线程持有一个锁，保护一个关键的系统资源，当它被破坏时，没有线程可以再次访问这个资源。如果另一个线程曾经试图锁定这个资源，就会产生死锁。 这种死锁通常表现为 "冻结 "进程。 更多信息，请参见《为什么Thread.stop、Thread.suspend和Thread.resume被废弃了？
另外，从 "Java Thread Primitive Deprecation" (上面链接的)。
Thread.destroy从未实施过。如果实现了，它就会像Thread.suspend一样容易产生死锁。事实上，它大致等同于Thread.suspend，没有后续Thread.resume的可能性）。我们目前没有实现它，但也没有废弃它（预留将来实现它的可能性）。虽然它肯定会容易产生死锁，但有人认为，在某些情况下，程序可能愿意冒着死锁的风险而不是直接退出。