完善目录

maskleo · maskleo · commit 609ea792b350 · 2018-04-24T22:39:28.000+08:00
diff --git a/README.md b/README.md
@@ -7,7 +7,6 @@
 将利用碎片时间进行整理和校对，完整的时间段适合做其他需要大量思考的事，如果你有兴趣欢迎提交PR。
 
 ## TODO
-- 目录完善
 - 数据校对
 
 ## 目录
@@ -78,9 +77,44 @@
     * [9.3 功能](ch09/03_Function.md#功能)
     * [9.4 策略](ch09/04_Strategy.md#策略)
     * [9.5 主题观察者](ch09/05_Subject-Observer.md#主题观察者)
-
-
-
+* [第二部分：集合](ch10/00_Collections.md#集合)
+  * [第十章(集合)](ch10/00_Collections.md#集合)
+    * [10.1 Java集合框架的主要接口](ch10/01_The_Main_Interfaces_of_the_Java.md#Java集合框架的主要接口)
+  * [第十一章(初步措施)](ch11/00_Preliminaries.md#初步措施)
+    * [11.1 可迭代和迭代器](ch11/01_Iterable_and_Iterators.md)
+    * [11.2 实现](ch11/02_Implementations.md)
+    * [11.3 效率与Ο符号](ch11/03_Efficiency_and_the_O-Notation.md#效率与Ο符号)
+    * [11.4 契约](ch11/04_contract.md#契约)
+    * [11.5 集合和线程安全](ch11/05_Collections_and_Thread_Safety.md#集合和线程安全)
+  * [第十二章(集合接口)](ch12/00_The_Collection_Interface.md#集合接口)
+    * [12.1 使用集合方法](ch12/01_Using_the_Methods_of_Collection.md#使用集合方法)
+    * [12.2 集合实现](ch12/02_Implementing_Collection.md#集合实现)
+    * [12.3 集合构造函数](ch12/03_Collection_Constructors.md#集合构造函数)
+  * [第十三章(Sets)](ch13/00_Sets.md#Sets)
+    * [13.1 实现Set](ch13/01_Implementing_Set.md#实现Set)
+    * [13.2 SortedSet和NavigableSet](ch13/02_SortedSet_and_NavigableSet.md#SortedSet和NavigableSet)
+  * [第十四章(Queues)](ch14/00_Queues.md#Queues)
+    * [14.1 使用队列方法](ch14/01_Using_the_Methods_of_Queue.md#使用队列方法)
+    * [14.2 队列的实现](ch14/02_Implementing_Queue.md#队列的实现)
+    * [14.3 BlockingQueue](ch14/03_BlockingQueue.md#BlockingQueue)
+    * [14.4 Deque](ch14/04_Deque.md#Deque)
+    * [14.5 比较队列实现](ch14/05_Comparing_Queue_Implementations.md#比较队列实现)
+  * [第十五章(Lists)](ch15/00_Lists.md#Lists)
+    * [15.1 使用List的方法](ch15/01_Using_the_Methods_of_List.md#使用List的方法)
+    * [15.2 实现List](ch15/02_Implementing_List.md#实现List)
+    * [15.3 比较List实现](ch15/03_Comparing_List_Implementations.md#比较List实现)
+  * [第十六章(Maps)](ch16/00_Maps.md#Maps)
+    * [16.1 使用Map的方法](ch16/01_Using_the_Methods_of_Map.md#使用Map的方法)
+    * [16.2 实现Map](ch16/02_Implementing_Map.md#实现Map)
+    * [16.3 SortedMap和NavigableMap](ch16/03_SortedMap_and_NavigableMap.md#SortedMap和NavigableMap)
+    * [16.4 ConcurrentMap](ch16/04_ConcurrentMap.md#ConcurrentMap)
+    * [16.5 ConcurrentNavigableMap](ch16/05_ConcurrentNavigableMap.md#ConcurrentNavigableMap)
+    * [16.6 比较Map的实现](ch16/06_Comparing_Map_Implementations.md#比较Map的实现)
+  * [第十七章(集合类)](ch17/00_The_Collections_Class.md#集合类)  
+    * [17.1 通用算法](ch17/01_Generic_Algorithms.md#通用算法)
+    * [17.2 收集工厂](ch17/02_Collection_Factories.md#收集工厂)
+    * [17.3 包装](ch17/03_Wrappers.md#包装)
+    * [17.4 其他方法](ch17/04_Other_Methods.md#其他方法)
 
 
 ## PR
diff --git a/ch10/01_The_Main_Interfaces_of_the_Java.md b/ch10/01_The_Main_Interfaces_of_the_Java.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](00_Collections.md)
 
-## Java集合框架的主要接口
+### Java集合框架的主要接口
 
 图 `10-1` 显示了 `Java` 集合框架的主要接口，以及另外一个 `Iterable`--它不在框架中，但是它是一个重要的附件。其目的如下：
 
diff --git a/ch11/01_Iterable_and_Iterators.md b/ch11/01_Iterable_and_Iterators.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](00_Preliminaries.md)
 
-## 可迭代和迭代器
+### 可迭代和迭代器
 
 迭代器是实现接口迭代器的对象
 
diff --git a/ch11/02_Implementations.md b/ch11/02_Implementations.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](01_Iterable_and_Iterators.md)
 
-## 实现
+### 实现
 
 我们简要地看了一下集合框架的接口，这些接口定义了我们可以预期的每个集合的行为。但正如我们在本章的介绍中提到的，有几种方法可以实现每个接口。为什么框架不会为每个接口使用最佳实现？那肯定会让生活变得更简单 - 事实上，过于简单就像生活一样。如果实施对某些行动来说是灰狗，墨菲定律告诉我们这对其他人来说将是一只乌龟。由于没有任何接口的“最佳”实现，所以您必须进行权衡，判断应用程序中哪些操作最常使用，并选择优化这些操作的实现。
 
diff --git a/ch11/03_Efficiency_and_the_O-Notation.md b/ch11/03_Efficiency_and_the_O-Notation.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](02_Implementations.md)
 
-## 效率与Ο符号
+### 效率与Ο符号
 
 在最后一节中，我们讨论了不同的实现对于不同的操作是“好的”。一个好的算法在使用两种资源时很经济：时间和空间。集合的实现通常使用与集合大小成正比的空间，但是访问和更新所需的时间可能会有很大差异，所以这将是我们的主要关心。很难说一个程序执行的速度有多快，因为这取决于很多因素，包括程序员省外的一些因素，比如编译代码的质量和硬件的速度。即使我们忽略了这些并且仅仅考虑算法的执行时间如何依赖于它的数据，详细的分析可能是复杂的。在 `Donald Knuth` 的经典着作“排序和搜索”（`Addison-Wesley`）中提供了一个相对简单的例子， `Knuth` 的名义 `MIX` 机器上的多列表插入排序程序的最坏情况执行时间推导为
 
diff --git a/ch11/04_contract.md b/ch11/04_contract.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](03_Efficiency_and_the_O-Notation.md)
 
-## 契约
+### 契约
 
 在阅读软件设计时，你很可能会遇到合同一词，通常没有任何附带的解释。事实上，软件工程给这个术语的含义非常接近人们通常理解合同的含义。在日常使用中，合同定
 义了双方可以期望的彼此之间 - 在某些交易中彼此承担的义务。如果合同规定了供应商向客户提供的服务，供应商的义务是显而易见的。但客户也可能有义务 - 除了支付
diff --git a/ch11/05_Collections_and_Thread_Safety.md b/ch11/05_Collections_and_Thread_Safety.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](04_contract.md)
 
-## 集合和线程安全
+### 集合和线程安全
 
 当一个 `Java` 程序正在运行时，它正在执行一个或多个执行流或线程。 线程就像一个轻量级进程，所以同时执行多个线程的程序可以被认为是同时运行多个程序的计算
 机，但是有一个重要区别：不同的线程可以同时访问相同的内存位置和其他系统资源。 在具有多个处理器的机器上，可以通过为每个线程分配处理器来实现真正的并发线
diff --git a/ch12/00_The_Collection_Interface.md b/ch12/00_The_Collection_Interface.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](../ch11/05_Collections_and_Thread_Safety.md)
 
-### 集合接口
+## 集合接口
 
 接口集合（参见图 `12-1`）定义了我们期望的除地图以外的任何集合的核心功能。 它提供了四组中的方法。
 
diff --git a/ch13/00_Sets.md b/ch13/00_Sets.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](../ch12/03_Collection_Constructors.md)
 
-### Sets
+## Sets
 
 一个集合是不能包含重复项目的集合; 如果它已经存在于集合中，则添加它不起作用。`Set` 接口的方法与 `Collection` 的方法相同，但它是分开定义的，以允许以这种方式更改 `add`（和 `addAll`，这是用 `add` 定义的）合约。 回到上一章中的任务管理器示例，假设星期一您有空闲时间执行电话任务。 您可以通过将所有电话任务添加到星期一任务来进行相应的收集。 让 `mondayTasks` 和 `phone` 任务如例 `12-1` 中所声明的那样。 使用一个集合（再次选择一个方便常见的 `Set` 实现），你可以写：
 
diff --git a/ch14/03_BlockingQueue.md b/ch14/03_BlockingQueue.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](02_Implementing_Queue.md)
 
-## BlockingQueue
+### BlockingQueue
 
 `Java 5` 为集合框架添加了许多类以供并发应用程序使用。其中大部分是 `Queue` 子接口 `BlockingQueue`（见图 `14-5`）的实现，主要用于生产者消费者队列。
 
diff --git a/ch14/04_Deque.md b/ch14/04_Deque.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](03_BlockingQueue.md)
 
-## Deque
+### Deque
 
 `deque`（发音为“deck”）是一个双端队列。与只能在尾部插入元素并仅在头部进行检查或删除的队列不同，`deque` 可以接受用于插入的元素并将其呈现在任一端进行检查或删除。与 `Queue` 不同的是，`Deque` 的合约指定了它在呈现元素时使用的顺序：它是一种线性结构，其中在尾部添加的元素在头部以相同的顺序排列。用作队列，那么 `Deque` 总是一个 `FIFO` 结构;合同不允许优先考虑。如果从添加元素的同一端（头部或尾部）删除元素，则 `Deque` 将用作堆栈或 `LIFO`（后进先出）结构。
 
diff --git a/ch14/05_Comparing_Queue_Implementations.md b/ch14/05_Comparing_Queue_Implementations.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](04_Deque.md)
 
-## 比较队列实现
+### 比较队列实现
 
 表 `14-1` 显示了我们讨论的 `Deque` 和 `Queue` 实现的一些示例操作的顺序性能，不考虑锁定和 `CAS` 开销。这些结果对于理解您选择的实现的行为而言应该很有意思，但正如我们在本章开头提到的那样，它们不可能是决定性因素。 您的选择更可能取决于应用程序的功能和并发性要求。
 
diff --git a/ch15/01_Using_the_Methods_of_List.md b/ch15/01_Using_the_Methods_of_List.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](00_Lists.md)
 
-## 使用List的方法
+### 使用List的方法
 
 让我们看看在待办事项管理器中使用其中一些方法的例子。 在上一章中，我们考虑使用关闭功能在一个基于队列的类中组织一天的任务。 扩大应用范围的一个有用的方法是拥有许多这种类型的对象，每个对象代表未来一天计划的任务。 我们将在一个 `List` 中存储对这些对象的引用，以便将它表示的将来的天数编入索引（保持简单并避免处理 `java.util.Calendar` 的令人厌恶的细节）。 因此，今天计划的任务队列将存储在列表的元素 `0` 处，明天排队等待在元素1处等待。 例 `15-1` 显示了调度程序。
 
diff --git a/ch15/02_Implementing_List.md b/ch15/02_Implementing_List.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](01_Using_the_Methods_of_List.md)
 
-## 实现List
+### 实现List
 
 在集合框架中有三个具体的 `List` 实现（参见图 `15-3`），它们执行界面定义的各种操作的速度以及它们在并发修改时的行为方式有所不同; 但是，与 `Set` 和 `Queue` 不同，`List` 没有子接口来指定功能行为的差异。 在本节和下一节中，我们依次查看每个实现并提供性能比较。
 
diff --git a/ch15/03_Comparing_List_Implementations.md b/ch15/03_Comparing_List_Implementations.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](02_Implementing_List.md)
 
-## 比较列表实现
+### 比较List实现
 
 表 `15-1` 给出了 `List` 类的一些样例操作的比较性能。即使这里的选择比队列甚至集合要窄得多，也可以使用相同的消除过程。与队列一样，首先要问的问题是您的应用程序是否需要线程安全。如果是这样，你应该使用 `CopyOnWriteArrayList`，如果可以的话 - 也就是说，如果写入列表会相对不频繁。如果没有，你将不得不围绕 `ArrayList` 或 `LinkedList` 使用一个同步包装器（见 `17.3.1` 节）。
 
diff --git a/ch16/01_Using_the_Methods_of_Map.md b/ch16/01_Using_the_Methods_of_Map.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](00_Maps.md)
 
-## 使用 Map 的方法
+### 使用Map的方法
 
 正如我们在前两章中所做的那样，将待办事项管理器置于优先级队列中的一个问题是优先级队列无法保留将元素添加到它们的顺序（除非可以按优先级顺序 例如作为时间戳或序列号）。 为了避免这种情况，我们可以使用一系列 `FIFO 队列作为替代模型，每个队列分配一个优先级。 一个 `Map` 适合于保持优先级与任务队列之间的关联; 特别是 `EnumMap` 是一个高效的 `Map` 实现，专门用于与枚举成员关键字一起使用。
 
diff --git a/ch16/02_Implementing_Map.md b/ch16/02_Implementing_Map.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](01_Using_the_Methods_of_Map.md)
 
-## 实现 Map
+### 实现Map
 
 图 `16-2` 显示了集合框架为 `Map` 提供的实现，共八个实例。 我们将在这里讨论 `HashMap`，`LinkedHashMap`，`WeakHashMap`，`IdentityHashMap` 和 `EnumMap`; 讨论 `NavigableMap`，`ConcurrentMap` 和 `ConcurrentNavigableMap` 的接口及其实现，以下部分。
 
diff --git a/ch16/03_SortedMap_and_NavigableMap.md b/ch16/03_SortedMap_and_NavigableMap.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](02_Implementing_Map.md)
 
-## SortedMap 和 NavigableMap
+### SortedMap和NavigableMap
 
 ![](16_5.png)
 
diff --git a/ch16/04_ConcurrentMap.md b/ch16/04_ConcurrentMap.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](03_SortedMap_and_NavigableMap.md)
 
-## ConcurrentMap
+### ConcurrentMap
 
 `Map` 通常用于高性能服务器应用程序中 - 例如，用作缓存实现 - 因此高吞吐量线程安全的地图实现是 `Java` 平台的重要组成部分。 同步地图（例如由 `Collections.synchronizedMap` 提供的 `Map`）无法满足此要求，因为在完全同步的情况下，每个操作都需要在整个地图上获得排他锁，从而有效地序列化对它的访问。 我们很快就会看到 `ConcurrentHashMap`，可以在吞吐量上获得非常大的增益，只锁定一部分集合。 但是因为客户端没有单独的锁来获得独占访问权限，所以客户端锁定不再起作用，并且客户端需要来自集合本身的帮助来执行原子动作。
 
diff --git a/ch16/05_ConcurrentNavigableMap.md b/ch16/05_ConcurrentNavigableMap.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](04_ConcurrentMap.md)
 
-## ConcurrentNavigableMap
+### ConcurrentNavigableMap
 
 ![](16_7.png)
 
diff --git a/ch16/06_Comparing_Map_Implementations.md b/ch16/06_Comparing_Map_Implementations.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](05_ConcurrentNavigableMap.md)
 
-## 比较 Map 的实现
+### 比较Map的实现
 
 表 `16-1` 显示了 `Map` 的不同平台实现的相对性能（“next”栏显示迭代器在密钥集上的下一次操作的开销）。 与队列的实现一样，您对 `map` 类的选择可能更多地受
 到应用程序的功能需求和所需的并发属性的影响。
diff --git a/ch17/01_Generic_Algorithms.md b/ch17/01_Generic_Algorithms.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](00_The_Collections_Class.md)
 
-## 通用算法
+### 通用算法
 
 通用算法分为四个主要类别：更改列表中的元素顺序，更改列表内容，查找集合中的极端值以及查找列表中的特定值。它们表示可重用的功能，因为它们可以应用于任何类型的列表（或在某些情况下适用于集合）。生成这些方法的类型导致了一些相当复杂的声明，因此每个部分都在声明之后简要地讨论这些声明。
 
diff --git a/ch17/02_Collection_Factories.md b/ch17/02_Collection_Factories.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](01_Generic_Algorithms.md)
 
-## 收集工厂
+### 收集工厂
 
 `Collections` 类提供了创建某些包含零个或多个对同一对象的引用的集合的简便方法。 最简单的这种集合是空的：
 
diff --git a/ch17/03_Wrappers.md b/ch17/03_Wrappers.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](02_Collection_Factories.md)
 
-## 包装
+### 包装
 
 `Collections` 类提供了包装对象，通过以下三种方式之一来修改标准集合类的行为：通过同步它们，使其不可修改，或通过检查添加到它们的元素的类型。这些包装器对象实现与包装对象相同的接口，并将它们的工作委托给它们。他们的目的是限制在哪些情况下进行这项工作。这些是使用保护代理的例子（参见 `Gamma`，`Helm`，`Johnson` 和 `Vlissides`，`Addison-Wesley` 的设计模式），代理模式的一个变体，代理控制对真实主体的访问。
 
diff --git a/ch17/04_Other_Methods.md b/ch17/04_Other_Methods.md
@@ -1,7 +1,7 @@
 《《《 [返回首页](../README.md)       <br/>
 《《《 [上一节](03_Wrappers.md)
 
-## 其他方法
+### 其他方法
 
 `Collections` 类提供了许多实用方法，其中一些我们已经看到使用。 我们在这里按字母顺序审查它们。
 
