为什么java.lang.Object不是抽象的？

Question

为什么Object类是Java中em的基类，而不是抽象类？

我已经有很长时间了，这个问题纯粹是出于好奇，仅此而已。我的代码或任何人的代码都没有中断，因为它不是抽象的，但是我想知道为什么他们将其具体化了？

为什么有人要这个Object类的“实例”（而不是引用的存在）？一种情况是糟糕的同步代码，该代码使用对象的实例进行锁定（至少我曾经以这种方式使用过一次……我的错）。

对象类的“实例”是否有实际用途？实例化如何适合OOP？如果他们将其标记为抽象，那将会发生什么（当然是在为其方法提供实现之后）？

Answer 1

如果没有设计师java.lang.Object告诉我们，我们就必须以意见为基础。有一些问题可以帮助您解决。

对象的任何方法都会从抽象中受益吗？

可以说某些方法将从中受益。以hashCode()和equals()举例来说，有可能早就少了很多挫折围绕这两个的复杂性，如果他们俩都已经取得抽象。这将要求开发人员弄清楚他们应该如何实现它们，从而使它们更加一致（请参见Effective
Java）更加明显。不过，我更认为hashCode()，equals()和clone()属于在不同的，选择在抽象（即接口）。其他方法，wait()，notify()，finalize()，等充分复杂和/或原产，所以最好他们已经实施，并不会被抽象受益。

因此，我猜答案是否定的，Object的任何方法都不会从抽象中受益。

将Object类标记为抽象是否有好处？

假设所有方法都已实现，则标记对象抽象的唯一效果是无法构造它（即，new Object()是编译错误）。这会有好处吗？我认为“对象”一词本身就是抽象的（可以在您周围找到可以完全描述为“对象”的任何东西吗？），因此它符合面向对象的范式。但是，它在
纯粹主义者 方面。可以说，强迫开发人员为任何具体的子类选择一个名称，即使是空的子类，也会导致代码更好地表达其意图。我认为，就范式而言，要完全 正确
，应该对对象进行标记abstract，但是当涉及到它时，并没有真正的好处，这是设计偏好的问题（实用主义vs.

使用纯对象进行同步的做法是否足以使其具体化？

其他许多答案都谈到了构造要在synchronized()操作中使用的普通对象。尽管这可能是一种普遍接受的做法，但我认为如果设计人员希望它成为防止Object抽象的足够理由，那么这还不是足够的理由。其他答案已经提到，我们想在某个对象上进行同步时，每次都必须声明一个单一的空子类，但这并不能成立-
SDK（java.lang.Lock或其他东西）中可能提供了一个空子类，可以在我们想要同步的任何时间构造它。这样做将具有创建更强有力的意图陈述的额外好处。

还有其他可能会因抽象对象而受到不利影响的因素吗？

从纯粹的设计观点来看，有几个领域可能会影响选择。不幸的是，我对它们还不够了解，无法扩展它们。但是，如果有任何一项对决定有影响，我不会感到惊讶：

• 性能
• 安全
• JVM实现的简单性

可能还有其他原因吗？

有人提到它可能与反射有关。但是，反射是在对象设计之后引入的。因此，不管它是否影响反射都没有意义-这不是原因。泛型相同。

还有一个让人难忘的一点，那就是java.lang.Object是人为设计的：他们可能犯了一个错误，他们可能没有考虑过这个问题。没有没有缺陷的语言，这
可能
是其中之一，但是如果存在缺陷，那简直不是什么大问题。而且我想我可以毫无保留地说，可以放心地说，我不太可能参与设计这种广泛使用的技术的关键部分，尤其是持续了15（？）年并且仍在不断发展的强大技术，因此不应被视为批评。

话虽如此，我会把它抽象化； -p

总结
就我所知，基本上，这两个问题的答案都是“为什么java.lang.Object是具体的？”
或（如果是如此）“为什么java.lang.Object是抽象的？” 是……“为什么不呢？”。