如果没有设计师
java.lang.Object告诉我们，我们就必须以意见为基础。有一些问题可以帮助您解决。
对象的任何方法都会从抽象中受益吗？
可以说某些方法将从中受益。以
hashCode()和
equals()举例来说，有可能早就少了很多挫折围绕这两个的复杂性，如果他们俩都已经取得抽象。这将要求开发人员弄清楚他们应该如何实现它们，从而使它们更加一致（请参见Effective
Java）更加明显。不过，我更认为
hashCode()，
equals()和
clone()属于在不同的，选择在抽象（即接口）。其他方法，
wait()，
notify()，
finalize()，等充分复杂和/或原产，所以最好他们已经实施，并不会被抽象受益。
因此，我猜答案是否定的，Object的任何方法都不会从抽象中受益。
将Object类标记为抽象是否有好处？
假设所有方法都已实现，则标记对象抽象的唯一效果是无法构造它（即，
newObject()是编译错误）。这会有好处吗？我认为“对象”一词本身就是抽象的（可以在您周围找到可以完全描述为“对象”的任何东西吗？），因此它符合面向对象的范式。但是，它在
纯粹主义者 方面。可以说，强迫开发人员为任何具体的子类选择一个名称，即使是空的子类，也会导致代码更好地表达其意图。我认为，就范式而言，要完全 正确
，应该对对象进行标记
abstract，但是当涉及到它时，并没有真正的好处，这是设计偏好的问题（实用主义vs.
使用纯对象进行同步的做法是否足以使其具体化？
其他许多答案都谈到了构造要在
synchronized()操作中使用的普通对象。尽管这可能是一种普遍接受的做法，但我认为如果设计人员希望它成为防止Object抽象的足够理由，那么这还不是足够的理由。其他答案已经提到，我们想在某个对象上进行同步时，每次都必须声明一个单一的空子类，但这并不能成立-
SDK（
java.lang.Lock或其他东西）中可能提供了一个空子类，可以在我们想要同步的任何时间构造它。这样做将具有创建更强有力的意图陈述的额外好处。
还有其他可能会因抽象对象而受到不利影响的因素吗？
从纯粹的设计观点来看，有几个领域可能会影响选择。不幸的是，我对它们还不够了解，无法扩展它们。但是，如果有任何一项对决定有影响，我不会感到惊讶：
- 性能
- 安全
- JVM实现的简单性
可能还有其他原因吗？
有人提到它可能与反射有关。但是，反射是在对象设计之后引入的。因此，不管它是否影响反射都没有意义-这不是原因。泛型相同。
还有一个让人难忘的一点，那就是java.lang.Object是人为设计的：他们可能犯了一个错误，他们可能没有考虑过这个问题。没有没有缺陷的语言，这
可能
是其中之一，但是如果存在缺陷，那简直不是什么大问题。而且我想我可以毫无保留地说，可以放心地说，我不太可能参与设计这种广泛使用的技术的关键部分，尤其是持续了15（？）年并且仍在不断发展的强大技术，因此不应被视为批评。
话虽如此，我会把它抽象化； -p
总结
就我所知，基本上，这两个问题的答案都是“为什么java.lang.Object是具体的？”
或（如果是如此）“为什么java.lang.Object是抽象的？” 是……“为什么不呢？”。
