java final thread_java - 为什么Thread不是抽象类而start（）不是final？

我觉得应该发布一些calirifcations作为答案：

“你确定你永远不想覆盖它吗？”

不！ 我不会。 多数民众赞成说：“你确定，你想把这个变量声明为私有吗？” 因为如果我可以声明我使用的任何变量而不用担心其他开发人员可能会弄乱我的设计逻辑，那么编码将是轻而易举的。 OOPS概念范围，抽象，多态，错误处理等最重要的目的之一就是向其他开发人员传达代码背后的设计和意图。正如问题所指出的，当你覆盖start方法时，没有人强迫你 使用super.start()。 @Codebender在不使用super.start()的情况下为线程编写了一个start方法，编译器从不抱怨。 所以他可以自由地打破整个线程机制，编译器假设让它通过？ Thread的start方法确保调用run方法并在正确的时间执行！ 这对于线程的概念至关重要。 如果我错过了这里的话，我会非常乐意得到纠正。2。

因为创建启动线程的推荐方法不是   子类线程。

好的，如果设计允许使用codebender，则子类Thread并搞乱start方法，按照这个逻辑，它就是设计射击本身的脚。  通过另一个声明(我完全同意)，Runnable是推荐的方式。 那么为什么我们允许Thread类完全实例化线程而没有任何限制呢？ 接下来是：

您不能自己替换start()的实现  实施

这实际上支持codebender声称当你说那个时，start方法应该是最终的。^

这一点是有效的，已作为附注提及，但这是这个问题的实际答案

“向后兼容性”。

实际上，甚至在JDK 5.0中也进行了改进，当时他们在Java并发模型中加入了许多重要的补充和说明。 我们希望一直支持向后兼容性，这就是为什么Thread类仍然与以前完全一样，即使Runnable接口是现在推荐的方式。

如果我错过了什么，我会非常高兴能够得到纠正。