为什么 Object 类（它是 Java 中所有类的基类）不是抽象的？
我这个问题已经问了很长一段时间了，这里纯粹是出于好奇，仅此而已。我的代码或任何人的代码中都没有破坏，因为它不是抽象的，但我想知道为什么他们把它具体化了？
为什么有人想要这个 Object 类的“实例”（而不是它的存在，又名引用）？一种情况是一个糟糕的同步代码，它使用Object的实例进行锁定（至少我曾经以这种方式使用它......我的坏）。
对象类的“实例”是否有任何实际用途？它的实例化如何适应 OOP？如果他们将其标记为抽象（当然是在为其方法提供实现之后），会发生什么？
没有设计师告诉我们，我们必须根据意见来回答。可以问几个问题，这些问题可能有助于澄清它。java.lang.Object
Object的任何方法都会从抽象中受益吗？
可以说，有些方法将从中受益。举个例子，如果这两者都是抽象的，那么对这两者的复杂性的挫败感可能会少得多。这将要求开发人员弄清楚他们应该如何实现它们，使它们更加明显地应该是一致的（参见有效的Java）。但是，我更认为，并且属于单独的，选择加入的抽象（即接口）。其他方法、、、 、 等足够复杂和/或是本机方法，因此最好它们已经实现，并且不会从抽象中受益。hashCode()equals()hashCode()equals()clone()wait()notify()finalize()
所以我想答案是否定的，Object的任何方法都不会从抽象中受益。
将 Object 类标记为抽象会有什么好处吗？
假设所有方法都已实现，则标记对象抽象的唯一效果是它无法构造（即 是编译错误）。这会有好处吗？我认为“对象”这个术语本身就是抽象的（你能在你周围找到任何可以完全描述为“对象”的东西吗？），所以它符合面向对象的范式。然而，这是在纯粹主义的一面。可以说，强迫开发人员为任何具体的子类选择一个名称，即使是空的子类，也会导致代码更好地表达他们的意图。我认为，为了在范式上完全正确，对象应该被标记为，但是当它归结为它时，没有真正的好处，这是一个设计偏好的问题（实用主义与纯度）。new Object()abstract
使用普通对象进行同步的做法是否足以成为具体的理由？
许多其他答案都在谈论构建一个在操作中使用的普通对象。虽然这可能是一种常见且被接受的做法，但我不认为如果设计师希望它成为抽象，这将是一个足够好的理由来防止Object是抽象的。其他答案已经提到，每当我们想要在某个对象上同步时，我们都必须声明Object的单个空子类，但这站不住脚 - 可以在SDK（或其他任何东西）中提供一个空的子类，可以随时构建我们想要同步。这样做将具有创建更强大的意图声明的额外好处。synchronized()java.lang.Lock
是否有任何其他因素可能会因使对象抽象而受到不利影响？
从纯粹的设计角度来看，有几个领域是分开的，这些领域可能会影响选择。不幸的是，我对它们的了解还不够多，无法扩展它们。但是，如果其中任何一个对决策产生影响，我也不会感到惊讶：
还有其他原因吗？
有人提到它可能与反思有关。但是，在对象设计之后引入了反射。因此，它是否影响反射是没有意义的 - 这不是原因。泛型也是如此。
还有一个令人难忘的观点是，java.lang.Object是由人类设计的：他们可能犯了一个错误，他们可能没有考虑过这个问题。没有一种语言没有缺陷，这可能是其中之一，但如果是这样，它几乎不是一个大问题。我想我可以肯定地说，在不缺乏雄心壮志的情况下，我不太可能参与设计这样一个广泛使用的技术的关键部分，特别是一个持续了15（？）年但仍然强大的技术，所以这不应该被认为是一种批评。
话虽如此，我会把它抽象出来;-p
基本上
，在我看来，“为什么java.lang.Object是具体的？”或（如果是这样的话）“为什么java.lang.Object abstract？”的答案是......“为什么不呢？
的普通实例通常用于锁定/同步方案，这是公认的做法。java.lang.Object
另外-它抽象的原因是什么？因为它本身作为一个实例并不完全起作用？它真的可以和一些抽象的成员一起做吗？不要这么认为。因此，首先使它抽象的论点是不存在的。事实并非如此。
以动物的经典层次结构为例，你有一个抽象类，使类抽象的原因是因为动物的实例实际上是一个“无效的” - 因为缺乏更好的词 - 动物（即使它的所有方法都提供了基本实现）。使用 ，则根本情况并非如此。首先，没有压倒性的理由使它抽象。AnimalAnimalObject
