我正在阅读TreeMap类型的Javadoc，惊讶地发现它明确要求TreeMap使用红/黑树作为其内部实现。不仅如此，它还专门为红/黑树挑出了一个特定的实现策略：
基于红黑树的NavigableMap实现。地图根据其键的自然顺序进行排序，或者由地图创建时提供的Comparator进行排序，具体取决于使用的构造函数。
此实现为包含键、获取、放置和删除操作提供了保证的log（n）时间成本。算法是对Cormen、Leiserson和Rivest的算法简介中的算法的改编。
我发现这很不寻常，因为我在Java留档中没有看到任何类似的东西（除了非常精确命名的类型，例如CopyOnWriteArrayList）。例如，如果你查看Collections.sort，没有提到应该使用什么排序算法。HashMap留档没有指定内部表示是否使用链式散列、线性探测、罗宾汉散列等。
我对此特别好奇，因为我习惯于阅读C规范，其中std::map的实现仅受复杂性保证和迭代器无效限制的约束。Cstd::map原则上可以实现为红/黑树，或替罪羊树，或splay树，甚至是确定性的skiplist。
为什么这里的Javadoc对< code>TreeMap的内部实现如此特别，以使其区别于其他类型，如< code>HashMap或其他算法原语，如排序或搜索，有什么记录在案的原因吗？我知道对于C ISO规范，有一个基本原理文档解释了委员会做出的许多决定，如果这里有类似的决定，我很想看看是什么。
这里的Javadoc对TreeMap的内部实现如此具体，是否有文件证明的原因可以将其与HashMap等其他类型或排序或搜索等其他算法原语区分开来？
简而言之，没有。
我知道对于C ISO规范，有一个基本原理文档解释了委员会做出的许多决定，如果这里有类似的决定，我很想看看是什么。
没有这样的（公开）文件来讨论Java的决定。至少，在过去的20年里，我没有遇到过。
>
Java设计人员的操作与C，C和ECMAscript的正式标准组不同。
由于javadocs嵌入在源代码中，因此必须由有权访问核心代码库的人员对它们进行实际更改。这将受类似于代码审查的过程的约束，而不是标准编写过程。
对于一些JSR团队来说，这可能有点不同，但实际上由各自的团队负责人决定他们选择记录多少（或很少）的理由。不同的JSR操作方式非常不同。
在这个阶段，任何人都能说的最好的一句话是，真正的原因已经失去了。实际上，我们并不确定这些javadocs最初是谁编写的，以及谁一直在维护它们。
我们知道的一件事是，随着时间的推移，Sun / Oracle在javadocs中包含的实现细节的数量上采取了不同的立场。例如< code>HashMap和< code>Arrays.sort的javadocs，其中细节的数量随着版本的不同而变化。
