ConcurrentHashMap设计思路解析

A hash table supporting full concurrency of retrievals and high expected concurrency for updates. This class obeys the same functional specification as Hashtable, and includes versions of methods corresponding to each method of Hashtable. However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access. This class is fully interoperable with Hashtable in programs that rely on its thread safety but not on its synchronization details.
Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset. (More formally, an update operation for a given key bears a happens-before relation with any (non-null) retrieval for that key reporting the updated value.) For aggregate operations such as putAll and clear, concurrent retrievals may reflect insertion or removal of only some entries. Similarly, Iterators, Spliterators and Enumerations return elements reflecting the state of the hash table at some point at or since the creation of the iterator/enumeration. They do not throw ConcurrentModificationException. However, iterators are designed to be used by only one thread at a time. Bear in mind that the results of aggregate status methods including size, isEmpty, and containsValue are typically useful only when a map is not undergoing concurrent updates in other threads. Otherwise the results of these methods reflect transient states that may be adequate for monitoring or estimation purposes, but not for program control.
The table is dynamically expanded when there are too many collisions (i.e., keys that have distinct hash codes but fall into the same slot modulo the table size), with the expected average effect of maintaining roughly two bins per mapping (corresponding to a 0.75 load factor threshold for resizing). There may be much variance around this average as mappings are added and removed, but overall, this maintains a commonly accepted time/space tradeoff for hash tables. However, resizing this or any other kind of hash table may be a relatively slow operation. When possible, it is a good idea to provide a size estimate as an optional initialCapacity constructor argument. An additional optional loadFactor constructor argument provides a further means of customizing initial table capacity by specifying the table density to be used in calculating the amount of space to allocate for the given number of elements. Also, for compatibility with previous versions of this class, constructors may optionally specify an expected concurrencyLevel as an additional hint for internal sizing. Note that using many keys with exactly the same hashCode() is a sure way to slow down performance of any hash table. To ameliorate impact, when keys are Comparable, this class may use comparison order among keys to help break ties.
A Set projection of a ConcurrentHashMap may be created (using newKeySet() or newKeySet(int)), or viewed (using keySet(Object) when only keys are of interest, and the mapped values are (perhaps transiently) not used or all take the same mapping value.
A ConcurrentHashMap can be used as scalable frequency map (a form of histogram or multiset) by using java.util.concurrent.atomic.LongAdder values and initializing via computeIfAbsent. For example, to add a count to a ConcurrentHashMap  freqs, you can use freqs.computeIfAbsent(k -> new LongAdder()).increment();
This class and its views and iterators implement all of the optional methods of the Map and Iterator interfaces.
Like Hashtable but unlike HashMap, this class does not allow null to be used as a key or value.
ConcurrentHashMaps support a set of sequential and parallel bulk operations that, unlike most Stream methods, are designed to be safely, and often sensibly, applied even with maps that are being concurrently updated by other threads; for example, when computing a snapshot summary of the values in a shared registry. There are three kinds of operation, each with four forms, accepting functions with Keys, Values, Entries, and (Key, Value) arguments and/or return values. Because the elements of a ConcurrentHashMap are not ordered in any particular way, and may be processed in different orders in different parallel executions, the correctness of supplied functions should not depend on any ordering, or on any other objects or values that may transiently change while computation is in progress; and except for forEach actions, should ideally be side-effect-free. Bulk operations on Map.Entry objects do not support method setValue.
forEach: Perform a given action on each element. A variant form applies a given transformation on each element before performing the action.
search: Return the first available non-null result of applying a given function on each element; skipping further search when a result is found.
reduce: Accumulate each element. The supplied reduction function cannot rely on ordering (more formally, it should be both associative and commutative). There are five variants:
Plain reductions. (There is not a form of this method for (key, value) function arguments since there is no corresponding return type.)
Mapped reductions that accumulate the results of a given function applied to each element.
Reductions to scalar doubles, longs, and ints, using a given basis value.
These bulk operations accept a parallelismThreshold argument. Methods proceed sequentially if the current map size is estimated to be less than the given threshold. Using a value of Long.MAX_VALUE suppresses all parallelism. Using a value of 1 results in maximal parallelism by partitioning into enough subtasks to fully utilize the ForkJoinPool.commonPool() that is used for all parallel computations. Normally, you would initially choose one of these extreme values, and then measure performance of using in-between values that trade off overhead versus throughput.
The concurrency properties of bulk operations follow from those of ConcurrentHashMap: Any non-null result returned from get(key) and related access methods bears a happens-before relation with the associated insertion or update. The result of any bulk operation reflects the composition of these per-element relations (but is not necessarily atomic with respect to the map as a whole unless it is somehow known to be quiescent). Conversely, because keys and values in the map are never null, null serves as a reliable atomic indicator of the current lack of any result. To maintain this property, null serves as an implicit basis for all non-scalar reduction operations. For the double, long, and int versions, the basis should be one that, when combined with any other value, returns that other value (more formally, it should be the identity element for the reduction). Most common reductions have these properties; for example, computing a sum with basis 0 or a minimum with basis MAX_VALUE.
Search and transformation functions provided as arguments should similarly return null to indicate the lack of any result (in which case it is not used). In the case of mapped reductions, this also enables transformations to serve as filters, returning null (or, in the case of primitive specializations, the identity basis) if the element should not be combined. You can create compound transformations and filterings by composing them yourself under this "null means there is nothing there now" rule before using them in search or reduce operations.
Methods accepting and/or returning Entry arguments maintain key-value associations. They may be useful for example when finding the key for the greatest value. Note that "plain" Entry arguments can be supplied using new AbstractMap.SimpleEntry(k,v).
Bulk operations may complete abruptly, throwing an exception encountered in the application of a supplied function. Bear in mind when handling such exceptions that other concurrently executing functions could also have thrown exceptions, or would have done so if the first exception had not occurred.
Speedups for parallel compared to sequential forms are common but not guaranteed. Parallel operations involving brief functions on small maps may execute more slowly than sequential forms if the underlying work to parallelize the computation is more expensive than the computation itself. Similarly, parallelization may not lead to much actual parallelism if all processors are busy performing unrelated tasks.
All arguments to all task methods must be non-null.
This class is a member of the Java Collections Framework.

一个哈希表，支持检索的完全并发性和更新的高预期并发性。这个类遵循与Hashtable相同的功能规范，并且包括与Hashtable的每个方法对应的方法版本。然而，即使所有操作都是线程安全的，检索操作也不需要锁定，并且不支持以阻止所有访问的方式锁定整个表。该类在依赖于其线程安全性但不依赖其同步细节的程序中与哈希表完全互操作。

检索操作（包括get）通常不会阻塞，因此可能与更新操作（包括put和remove）重叠。检索反映了最近完成的更新操作在开始时的结果。（更正式地说，给定密钥的更新操作与报告更新值的该密钥的任何（非null）检索具有“发生在前”关系。）对于putAll和clear等聚合操作，并发检索可能只反映插入或删除某些条目。类似地，迭代器、拆分器和枚举返回反映哈希表在迭代器/枚举创建时或创建之后某个点的状态的元素。他们不会抛出ConcurrentModificationException。然而，迭代器被设计为一次只能由一个线程使用。请记住，聚合状态方法（包括size、isEmpty和containsValue）的结果通常只有在其他线程中没有同步更新映射时才有用。否则，这些方法的结果反映的瞬态可能足以用于监测或估计目的，但不适用于程序控制。

当冲突太多时（即，键具有不同的哈希代码，但落入以表大小为模的同一插槽），表会动态扩展，预期的平均效果是每个映射保持大约两个存储单元（对应于0.75的负载因子阈值）。随着映射的添加和删除，这个平均值可能会有很大的差异，但总的来说，这为哈希表保持了一个普遍接受的时间/空间权衡。然而，调整这个或任何其他类型的哈希表的大小可能是一个相对缓慢的操作。如果可能，最好提供一个大小估计值作为可选的initialCapacity构造函数参数。另外一个可选的loadFactor构造函数参数提供了一种定制初始表容量的进一步方法，它指定了在计算为给定数量的元素分配的空间量时要使用的表密度。此外，为了与该类的早期版本兼容，构造函数可以选择指定预期的并发级别，作为内部大小调整的额外提示。请注意，使用具有完全相同hashCode（）的多个键肯定会降低任何哈希表的性能。为了改善影响，当键具有可比性时，该类可以使用键之间的比较顺序来帮助打破联系。

ConcurrentHashMap的集合投影可以创建（使用newKeySet（）或newKeySet（int）），也可以查看（使用keySet（Object）），前提是只有键感兴趣，并且映射的值（可能暂时）没有使用，或者全部采用相同的映射值。

通过使用java，ConcurrentHashMap可以用作可伸缩频率图（直方图或多集的一种形式）。util。同时发生的原子的LongAdder值并通过ComputeFabSent初始化。例如，要向ConcurrentHashMap freqs添加计数，可以使用freqs。computeIfAbsent（k->new LongAdder（）。增量（）；

这个类及其视图和迭代器实现了映射和迭代器接口的所有可选方法。

与Hashtable类似，但与HashMap不同，该类不允许将null用作键或值。

ConcurrentHashMaps支持一组顺序和并行批量操作，与大多数流方法不同，这些操作被设计为安全且通常合理地应用于其他线程同时更新的映射；例如，在计算共享注册表中的值的快照摘要时。有三种操作，每种操作有四种形式，接受带有键、值、条目和（键、值）参数和/或返回值的函数。因为ConcurrentHashMap的元素没有以任何特定的方式排序，并且可以在不同的并行执行中以不同的顺序进行处理，所以提供的函数的正确性不应该取决于任何排序，或者在计算过程中可能暂时改变的任何其他对象或值；除了forEach动作外，最好不要有副作用。在地图上进行批量操作。条目对象不支持方法setValue。

forEach：对每个元素执行给定的操作。变量形式在执行操作之前对每个元素应用给定的转换。

搜索：返回对每个元素应用给定函数的第一个可用非空结果；找到结果时跳过进一步搜索。

减少：积累每种元素。提供的约化函数不能依赖于排序（更正式地说，它应该是关联的和交换的）。有五种变体：

简单的削减。（对于（key，value）函数参数，没有此方法的一种形式，因为没有相应的返回类型。）

将给定函数的结果累加到每个元素上的映射约化。

使用给定的基值，将约化为标量double、long和int。

这些批量操作接受parallelismThreshold参数。如果当前地图大小估计小于给定的阈值，方法将按顺序进行。使用Long的值。最大值会抑制所有并行性。使用值1可以通过划分足够多的子任务来充分利用ForkJoinPool，从而实现最大的并行性。commonPool（），用于所有并行计算。通常，您首先会选择这些极值中的一个，然后在权衡开销和吞吐量的值之间测量使用的性能。

大容量操作的并发属性遵循ConcurrentHashMap的并发属性：从get（key）和相关访问方法返回的任何非空结果都与相关的插入或更新具有“发生在”关系。任何批量操作的结果都反映了这些每元素关系的组成（但就整个映射而言，不一定是原子的，除非知道它是静态的）。相反，由于映射中的键和值从不为null，因此null可以作为当前缺少任何结果的可靠原子指示器。为了维护这个属性，null作为所有非标量缩减操作的隐式基础。对于double、long和int版本，基础应该是一个，当与任何其他值组合时，返回该其他值（更正式地说，它应该是归约的标识元素）。大多数常见的约化都有这些性质；例如，计算基数为0的和或基数为MAX_值的最小值。

作为参数提供的搜索和转换函数同样应该返回null，以指示缺少任何结果（在这种情况下不使用）。在映射归约的情况下，这还允许转换充当过滤器，如果不应组合元素，则返回null（或者在原语专门化的情况下，返回标识基）。在搜索或reduce操作中使用复合转换和过滤器之前，可以根据“null意味着现在什么都没有”规则自行组合它们，从而创建复合转换和过滤器。

接受和/或返回入口参数的方法维护键值关联。例如，在找到最大值的键时，它们可能很有用。请注意，可以使用新的AbstractMap提供“普通”条目参数。简单尝试（k，v）。

批量操作可能会突然完成，从而引发在应用提供的函数时遇到的异常。请记住，在处理此类异常时，其他并发执行的函数也可能抛出异常，或者在第一个异常未发生时也会抛出异常。

与顺序形式相比，并行形式的加速是常见的，但不能保证。如果使计算并行化的底层工作比计算本身更昂贵，则涉及小映射上的简短函数的并行操作可能比顺序形式执行得慢。类似地，如果所有处理器都忙于执行不相关的任务，并行化可能不会带来太多实际的并行性。

所有任务方法的所有参数都必须为非null。

此类是Java集合框架的成员。

/*
 * Overview:
 *
 * The primary design goal of this hash table is to maintain
 * concurrent readability (typically method get(), but also
 * iterators and related methods) while minimizing update
 * contention. Secondary goals are to keep space consumption about
 * the same or better than java.util.HashMap, and to support high
 * initial insertion rates on an empty table by many threads.
 *
 * This map usually acts as a binned (bucketed) hash table.  Each
 * key-value mapping is held in a Node.  Most nodes are instances
 * of the basic Node class with hash, key, value, and next
 * fields. However, various subclasses exist: TreeNodes are
 * arranged in balanced trees, not lists.  TreeBins hold the roots
 * of sets of TreeNodes. ForwardingNodes are placed at the heads
 * of bins during resizing. ReservationNodes are used as
 * placeholders while establishing values in computeIfAbsent and
 * related methods.  The types TreeBin, ForwardingNode, and
 * ReservationNode do not hold normal user keys, values, or
 * hashes, and are readily distinguishable during search etc
 * because they have negative hash fields and null key and value
 * fields. (These special nodes are either uncommon or transient,
 * so the impact of carrying around some unused fields is
 * insignificant.)
 *
 * The table is lazily initialized to a power-of-two size upon the
 * first insertion.  Each bin in the table normally contains a
 * list of Nodes (most often, the list has only zero or one Node).
 * Table accesses require volatile/atomic reads, writes, and
 * CASes.  Because there is no other way to arrange this without
 * adding further indirections, we use intrinsics
 * (sun.misc.Unsafe) operations.
 *
 * We use the top (sign) bit of Node hash fields for control
 * purposes -- it is available anyway because of addressing
 * constraints.  Nodes with negative hash fields are specially
 * handled or ignored in map methods.
 *
 * Insertion (via put or its variants) of the first node in an
 * empty bin is performed by just CASing it to the bin.  This is
 * by far the most common case for put operations under most
 * key/hash distributions.  Other update operations (insert,
 * delete, and replace) require locks.  We do not want to waste
 * the space required to associate a distinct lock object with
 * each bin, so instead use the first node of a bin list itself as
 * a lock. Locking support for these locks relies on builtin
 * "synchronized" monitors.
 *
 * Using the first node of a list as a lock does not by itself
 * suffice though: When a node is locked, any update must first
 * validate that it is still the first node after locking it, and
 * retry if not. Because new nodes are always appended to lists,
 * once a node is first in a bin, it remains first until deleted
 * or the bin becomes invalidated (upon resizing).
 *
 * The main disadvantage of per-bin locks is that other update
 * operations on other nodes in a bin list protected by the same
 * lock can stall, for example when user equals() or mapping
 * functions take a long time.  However, statistically, under
 * random hash codes, this is not a common problem.  Ideally, the
 * frequency of nodes in bins follows a Poisson distribution
 * (http://en.wikipedia.org/wiki/Poisson_distribution) with a
 * parameter of about 0.5 on average, given the resizing threshold
 * of 0.75, although with a large variance because of resizing
 * granularity. Ignoring variance, the expected occurrences of
 * list size k are (exp(-0.5) * pow(0.5, k) / factorial(k)). The
 * first values are:
 *
 * 0:    0.60653066
 * 1:    0.30326533
 * 2:    0.07581633
 * 3:    0.01263606
 * 4:    0.00157952
 * 5:    0.00015795
 * 6:    0.00001316
 * 7:    0.00000094
 * 8:    0.00000006
 * more: less than 1 in ten million
 *
 * Lock contention probability for two threads accessing distinct
 * elements is roughly 1 / (8 * #elements) under random hashes.
 *
 * Actual hash code distributions encountered in practice
 * sometimes deviate significantly from uniform randomness.  This
 * includes the case when N > (1<<30), so some keys MUST collide.
 * Similarly for dumb or hostile usages in which multiple keys are
 * designed to have identical hash codes or ones that differs only
 * in masked-out high bits. So we use a secondary strategy that
 * applies when the number of nodes in a bin exceeds a
 * threshold. These TreeBins use a balanced tree to hold nodes (a
 * specialized form of red-black trees), bounding search time to
 * O(log N).  Each search step in a TreeBin is at least twice as
 * slow as in a regular list, but given that N cannot exceed
 * (1<<64) (before running out of addresses) this bounds search
 * steps, lock hold times, etc, to reasonable constants (roughly
 * 100 nodes inspected per operation worst case) so long as keys
 * are Comparable (which is very common -- String, Long, etc).
 * TreeBin nodes (TreeNodes) also maintain the same "next"
 * traversal pointers as regular nodes, so can be traversed in
 * iterators in the same way.
 *
 * The table is resized when occupancy exceeds a percentage
 * threshold (nominally, 0.75, but see below).  Any thread
 * noticing an overfull bin may assist in resizing after the
 * initiating thread allocates and sets up the replacement array.
 * However, rather than stalling, these other threads may proceed
 * with insertions etc.  The use of TreeBins shields us from the
 * worst case effects of overfilling while resizes are in
 * progress.  Resizing proceeds by transferring bins, one by one,
 * from the table to the next table. However, threads claim small
 * blocks of indices to transfer (via field transferIndex) before
 * doing so, reducing contention.  A generation stamp in field
 * sizeCtl ensures that resizings do not overlap. Because we are
 * using power-of-two expansion, the elements from each bin must
 * either stay at same index, or move with a power of two
 * offset. We eliminate unnecessary node creation by catching
 * cases where old nodes can be reused because their next fields
 * won't change.  On average, only about one-sixth of them need
 * cloning when a table doubles. The nodes they replace will be
 * garbage collectable as soon as they are no longer referenced by
 * any reader thread that may be in the midst of concurrently
 * traversing table.  Upon transfer, the old table bin contains
 * only a special forwarding node (with hash field "MOVED") that
 * contains the next table as its key. On encountering a
 * forwarding node, access and update operations restart, using
 * the new table.
 *
 * Each bin transfer requires its bin lock, which can stall
 * waiting for locks while resizing. However, because other
 * threads can join in and help resize rather than contend for
 * locks, average aggregate waits become shorter as resizing
 * progresses.  The transfer operation must also ensure that all
 * accessible bins in both the old and new table are usable by any
 * traversal.  This is arranged in part by proceeding from the
 * last bin (table.length - 1) up towards the first.  Upon seeing
 * a forwarding node, traversals (see class Traverser) arrange to
 * move to the new table without revisiting nodes.  To ensure that
 * no intervening nodes are skipped even when moved out of order,
 * a stack (see class TableStack) is created on first encounter of
 * a forwarding node during a traversal, to maintain its place if
 * later processing the current table. The need for these
 * save/restore mechanics is relatively rare, but when one
 * forwarding node is encountered, typically many more will be.
 * So Traversers use a simple caching scheme to avoid creating so
 * many new TableStack nodes. (Thanks to Peter Levart for
 * suggesting use of a stack here.)
 *
 * The traversal scheme also applies to partial traversals of
 * ranges of bins (via an alternate Traverser constructor)
 * to support partitioned aggregate operations.  Also, read-only
 * operations give up if ever forwarded to a null table, which
 * provides support for shutdown-style clearing, which is also not
 * currently implemented.
 *
 * Lazy table initialization minimizes footprint until first use,
 * and also avoids resizings when the first operation is from a
 * putAll, constructor with map argument, or deserialization.
 * These cases attempt to override the initial capacity settings,
 * but harmlessly fail to take effect in cases of races.
 *
 * The element count is maintained using a specialization of
 * LongAdder. We need to incorporate a specialization rather than
 * just use a LongAdder in order to access implicit
 * contention-sensing that leads to creation of multiple
 * CounterCells.  The counter mechanics avoid contention on
 * updates but can encounter cache thrashing if read too
 * frequently during concurrent access. To avoid reading so often,
 * resizing under contention is attempted only upon adding to a
 * bin already holding two or more nodes. Under uniform hash
 * distributions, the probability of this occurring at threshold
 * is around 13%, meaning that only about 1 in 8 puts check
 * threshold (and after resizing, many fewer do so).
 *
 * TreeBins use a special form of comparison for search and
 * related operations (which is the main reason we cannot use
 * existing collections such as TreeMaps). TreeBins contain
 * Comparable elements, but may contain others, as well as
 * elements that are Comparable but not necessarily Comparable for
 * the same T, so we cannot invoke compareTo among them. To handle
 * this, the tree is ordered primarily by hash value, then by
 * Comparable.compareTo order if applicable.  On lookup at a node,
 * if elements are not comparable or compare as 0 then both left
 * and right children may need to be searched in the case of tied
 * hash values. (This corresponds to the full list search that
 * would be necessary if all elements were non-Comparable and had
 * tied hashes.) On insertion, to keep a total ordering (or as
 * close as is required here) across rebalancings, we compare
 * classes and identityHashCodes as tie-breakers. The red-black
 * balancing code is updated from pre-jdk-collections
 * (http://gee.cs.oswego.edu/dl/classes/collections/RBCell.java)
 * based in turn on Cormen, Leiserson, and Rivest "Introduction to
 * Algorithms" (CLR).
 *
 * TreeBins also require an additional locking mechanism.  While
 * list traversal is always possible by readers even during
 * updates, tree traversal is not, mainly because of tree-rotations
 * that may change the root node and/or its linkages.  TreeBins
 * include a simple read-write lock mechanism parasitic on the
 * main bin-synchronization strategy: Structural adjustments
 * associated with an insertion or removal are already bin-locked
 * (and so cannot conflict with other writers) but must wait for
 * ongoing readers to finish. Since there can be only one such
 * waiter, we use a simple scheme using a single "waiter" field to
 * block writers.  However, readers need never block.  If the root
 * lock is held, they proceed along the slow traversal path (via
 * next-pointers) until the lock becomes available or the list is
 * exhausted, whichever comes first. These cases are not fast, but
 * maximize aggregate expected throughput.
 *
 * Maintaining API and serialization compatibility with previous
 * versions of this class introduces several oddities. Mainly: We
 * leave untouched but unused constructor arguments refering to
 * concurrencyLevel. We accept a loadFactor constructor argument,
 * but apply it only to initial table capacity (which is the only
 * time that we can guarantee to honor it.) We also declare an
 * unused "Segment" class that is instantiated in minimal form
 * only when serializing.
 *
 * Also, solely for compatibility with previous versions of this
 * class, it extends AbstractMap, even though all of its methods
 * are overridden, so it is just useless baggage.
 *
 * This file is organized to make things a little easier to follow
 * while reading than they might otherwise: First the main static
 * declarations and utilities, then fields, then main public
 * methods (with a few factorings of multiple public methods into
 * internal ones), then sizing methods, trees, traversers, and
 * bulk operations.
 */

概述：

*

*这个哈希表的主要设计目标是维护

*并发可读性（通常是方法get（），但是

*迭代器和相关方法），同时最小化更新

*争论。第二个目标是将空间消耗保持在

*与java相同或更好。util。HashMap，并支持高

*许多线程在空表上的初始插入速率。

*

*该映射通常充当一个装箱（带扣）的哈希表。每个

*键值映射保存在节点中。大多数节点都是实例

*包含哈希、键、值和下一步的基本节点类的

*菲尔德。然而，有各种各样的亚类存在：TreeNodes是

*以平衡的树排列，而不是列表。树的根是树的

*一组树节点。转发节点放置在头部

*重新调整大小期间的垃圾箱数量。ReservationNodes用作

*在ComputeFabSent和中建立值时的占位符

*相关方法。TreeBin、ForwardingNode和

*ReservationNode不保存普通用户密钥、值或

*散列，并且在搜索等过程中易于区分

*因为它们有负的散列字段和空的键和值

*菲尔德。（这些特殊节点要么不常见，要么短暂，

*因此，携带一些未使用的土地的影响是

*无关紧要。）

*

*表被惰性地初始化为两个大小的幂

*第一次插入。表中的每个箱子通常包含一个

*节点列表（通常，该列表只有零个或一个节点）。

*表访问需要易失性/原子性读、写和

*案例。因为没有别的办法来安排

*再加上更多的间接性，我们使用本质

*（太阳杂项不安全）操作。

*

*我们使用节点散列字段的顶部（符号）位进行控制

*目的——由于寻址，它仍然可用

*限制。具有负散列字段的节点是特殊的

*在映射方法中处理或忽略。

*

*插入（通过put或其变体）网络中的第一个节点

*清空垃圾箱只需将其装入垃圾箱即可。这是

*到目前为止，最常见的情况是在大多数情况下进行put操作

*密钥/散列分布。其他更新操作（插入、，

*删除和替换）需要锁定。我们不想浪费

*将不同的锁对象与关联所需的空间

*每个箱子，所以使用箱子列表本身的第一个节点作为

*一把锁。这些锁的锁定支持依赖于内置

*“同步”监视器。

*

*将列表的第一个节点用作锁本身并不会

*不过足够了：当一个节点被锁定时，任何更新都必须首先进行

*验证锁定后它仍然是第一个节点，以及

*如果没有，请重试。因为新节点总是附加到列表中，

*一旦一个节点在bin中是第一个节点，它将保持第一个节点，直到被删除

*或者箱子失效（调整大小后）。

*

*每箱锁的主要缺点是其他更新

*bin列表中其他节点上的操作受到相同的保护

*锁定可能会暂停，例如当用户等于（）或映射时

*函数需要很长时间。然而，从统计数据来看

*随机散列码，这不是常见的问题。理想情况下

*箱中节点的频率遵循泊松分布

* (http://en.wikipedia.org/wiki/Poisson_distribution)带着

*给定大小调整阈值，参数平均约为0.5

*为0.75，但由于大小调整，差异较大

*粒度。忽略方差，则

*列表大小k是（exp（-0.5）*pow（0.5，k）/阶乘（k））。这个

*第一个值是：

*

* 0: 0.60653066

* 1: 0.30326533

* 2: 0.07581633

* 3: 0.01263606

* 4: 0.00157952

* 5: 0.00015795

* 6: 0.00001316

* 7: 0.00000094

* 8: 0.00000006

*更多：不到一千万分之一

*

*访问不同线程的两个线程的锁争用概率

*元素在随机散列下大约为1/（8*#元素）。

*

*实践中遇到的实际哈希代码分布

*有时明显偏离均匀随机性。这

*包括N>（1<<30）时的情况，因此某些关键点必须碰撞。

*类似地，对于多个键同时存在的愚蠢或敌对用途

*设计为具有相同的散列码或仅不同的散列码

*在隐藏的高位。所以我们使用了一种次要策略

*当bin中的节点数超过

*门槛。这些树形图使用平衡树来保存节点（a

*红黑树的特殊形式），限定了搜索时间

*O（logn）。TreeBin中的每个搜索步骤至少是

*和常规列表一样慢，但考虑到N不能超过

*（1<<64）（在地址用完之前）此边界搜索

*将步数、锁定保持时间等设置为合理常数（大致为

*每个操作检查100个节点（最坏情况下），只要钥匙

*具有可比性（这是非常常见的——字符串、长字符串等）。

*TreeBin节点（TreeNodes）也保持相同的“下一步”

*遍历指针作为常规节点，因此可以在

*迭代器也是这样。

*

*当占用率超过某个百分比时，该表将调整大小

*阈值（名义上为0.75，但见下文）。任何线索

*注意到垃圾箱过满可能会有助于在垃圾箱关闭后调整大小

*启动线程分配并设置替换数组。

*但是，这些其他线程可能会继续，而不是暂停

*通过插入等方式，树莓的使用保护我们免受疾病的侵袭

*调整尺寸时过度填充的最坏情况影响

*进步。通过一个接一个地转移垃圾箱来调整收益，

*从这张桌子到下一张桌子。然而，线程声称很小

*之前要传输的索引块（通过字段transferIndex）

*这样做可以减少争论。田野里的一代人

*sizeCtl确保大小调整不会重叠。因为我们是

*使用两次膨胀的力量，每个箱子的元件必须

*要么保持在同一指数，要么以二的幂移动

*抵消。我们通过捕获来消除不必要的节点创建

*旧节点可以重用的情况，因为它们的下一个字段

*不会改变。平均而言，只有大约六分之一的人需要帮助

*当一张桌子翻倍时进行克隆。它们替换的节点将是

*一旦它们不再被引用，就可以立即收集垃圾

*任何可能处于同步状态的读卡器线程

*遍历表。在转移时，旧表箱包含

*只有一个特殊的转发节点（哈希字段“已移动”）可以

*包含下一个表作为其键。在遇到

*转发节点、访问和更新操作重新启动，使用

*新桌子。

*

*每个垃圾箱传送都需要其垃圾箱锁，这可能会暂停

*调整大小时等待锁定。然而，由于其他原因

*线程可以加入并帮助调整大小，而不是争夺

*锁，平均聚合等待时间会随着大小调整而变短

*进步。传输操作还必须确保

*旧桌子和新桌子上的无障碍垃圾箱可供任何人使用

*穿越。这在一定程度上是从

*最后一个垃圾箱（table.length-1）向上朝向第一个。一见

*一个转发节点，遍历（参见类遍历器）安排

*在不重新访问节点的情况下移动到新表。为了确保

*即使无序移动，也不会跳过任何中间节点，

*堆栈（参见类TableStack）是在第一次遇到

*在遍历过程中的转发节点，在以下情况下保持其位置：

*稍后处理当前表。需要这些

*保存/恢复机制相对较少，但是

*遇到转发节点时，通常会遇到更多。

*因此，遍历器使用简单的缓存方案来避免创建

*许多新的TableStack节点。（感谢彼得·莱瓦特的支持。）

*建议在此处使用堆栈。）

*

*遍历方案也适用于

*箱子范围（通过备用遍历器构造函数）

*支持分区聚合操作。而且是只读的

*如果将操作转发到空表，则会放弃，而空表

*提供对关机方式清除的支持，但也不支持

*目前正在实施。

*

*惰性表初始化在首次使用前将占用空间最小化，

*而且，当第一个操作来自

*putAll、带映射参数的构造函数或反序列化。

*这些情况试图覆盖初始容量设置，

*但在种族问题上却没有起到无害的作用。

*

*元素计数使用

*龙加法。我们需要专业化，而不是

*只需使用一个长加法器就可以访问隐式

*竞争感知导致多个

*反细胞。反机制避免了在这个问题上的争论

*更新，但如果读取太多，可能会遇到缓存抖动

*在并发访问期间经常出现。为了避免经常阅读，

*只有在添加到

*bin已包含两个或多个节点。在一致散列下

*分布，这在阈值发生的概率

*大约是13%，这意味着只有大约八分之一的人会付账

*阈值（调整大小后，这样做的人要少得多）。

*

*树比因使用一种特殊的比较形式进行搜索和分析

*相关操作（这是我们无法使用的主要原因）

*现有集合（如树形图）。树蜘蛛含有

*可比元素，但可能包含其他元素，以及

*具有可比性但不一定具有可比性的元素

*相同的T，所以我们不能在它们之间调用compareTo。处理

*在这种情况下，树主要按哈希值排序，然后按

*可比。如果适用，请与订单进行比较。在节点上查找时，

*如果元素不可比较或比较为0，则两者均为左

*如果孩子被绑住了，可能需要搜查正确的孩子

*散列值。（这对应于

*如果所有元素都不可比较且具有

*绑定哈希。）插入时，保持总的顺序（或作为

*按此处要求关闭）ac

*我们比较了不同的再平衡

*类别和识别代码为联络断路器。红黑

*平衡代码是从jdk之前的集合中更新的

* (http://gee.cs.oswego.edu/dl/classes/collections/RBCell.java)

*依次基于Cormen、Leiserson和Rivest的《关于

*算法”（CLR）。

*

*树蛋白还需要额外的锁定机制。虽然

*读者即使在阅读过程中也可以遍历列表

*更新时，树遍历不是，主要是因为树旋转

*这可能会改变根节点和/或其链接。树蜘蛛

*包括寄生在主机上的简单读写锁定机制

*主要同步策略：结构调整

*与插入或删除关联的文件已被锁定

*（因此不能与其他作家发生冲突）但必须等待

*正在进行的阅读需要完成。因为只有一个这样的

*服务员，我们使用一个简单的方案，使用一个“服务员”字段

*街区作家。然而，读者永远不需要封锁。如果根

*锁定时，它们沿着缓慢的穿越路径（通过

*下一个指针），直到锁可用或列表

*精疲力竭，以先到者为准。这些病例并不迅速，但

*最大化总预期吞吐量。

*

*维护API和序列化与以前版本的兼容性

*这个类的版本引入了几个奇怪的地方。主要是：我们

*保留未触及但未使用的构造函数参数，引用

*高水平。我们接受loadFactor构造函数参数，

*但只适用于初始表容量（这是唯一的

*我们可以保证遵守的时间。）我们还宣布

*以最小形式实例化的未使用的“段”类

*只有在序列化时。

*

*此外，仅为了与本产品的早期版本兼容

*类，它扩展了AbstractMap，尽管它的所有方法

*都被覆盖了，所以这只是无用的行李。

*

*这个文件的组织是为了让事情更容易理解

*在阅读时，他们可能会比其他情况下：首先是主要的静态

*声明和实用程序，然后是字段，然后是主公共

*方法（将多个公共方法分解为

*内部的），然后是大小调整方法、树、遍历器和

*批量操作。