在正常发育，HashMap,HashTable,HashSet 他们批准了经常使用的按键值地图数据结构。在这里，我主要写一些平时我们使用的这些数据结构easy忽略。
HashMap
HashMap的结构
HashMap 底层是一个Entry数组来支撑的。我认为叫Entry链表数组支撑更为合适。
结构图:
每一个entry数组里面的元素要么为null要么就是一个entry链表；而每一个entry对象就是一个entry链表的节点也是一个键值对的抽象表示；
HashMap的性能因素
HashMap主要影响其性能的有两个因素，一个是初始容量。一个是加载因子；HashMap(int initialCapacity初始容量, float loadFactor加载因子)，我们在遍历HashMap的时候，会对整个数组都进行遍历。也就是说性能跟entry数组的长度有关（容量）。假设将初始容量设置的过大。实际上我们没装几个东西在里面，那么遍历的时候。会遍历全部数组组元素。这里已经指出了，我们不希望容量设置的过大。那么当put数据的时候检測到容量超过我们的阀值threshold。就会又一次构造一个两倍的数组出来，从而达到扩容的母的。
if (size++ >= threshold) resize(2 * table.length); threshold = 当前容量*loadFactor加载因子。
我们始终要抓住一点，HashMap要常常遍历。我们应该让他在合适的时间选择扩容，避免过早的遍历更大的容量数组。所以我们应当尽量避免将loadFactor设置的过小。
哈希冲突
当我们put两个元素的时候，假设他们的哈希值都一样，或者说哈希值不一样。可是数组下标一样的时候，那么究竟谁该放在同个槽里呢？这就是通俗的哈希冲突。为了解决哈希冲突。jdk採用链表的方式来解决哈希值的冲突。
以下我们看看源代码来分析。
public V put(K key, V value) {
if (key == null)
return putForNullKey(value);
int hash = hash(key.hashCode());//计算键的哈希值
int i = indexFor(hash, table.length);//找到该哈希值相应的entry数组下标
for (Entry<K,V> e = table[i]; e != null; e = e.next) {//假设entry数组下标相应的entry链表里面，put之前就存在与这个指定的key关联的entry对象。那么直接替换旧的value。并返回这个旧的value给调用者。
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {//当哈希算法计算出来的哈希值同样，而且（key是同一个对象||两个key equals推断同样)即表示存在旧的key关联的entry
V oldValue = e.value;
e.value = value;
e.recordAccess(this);//这个 hashMap 无需关心。
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);//当entry数组下标相应的entry链表没有与指定的key关联的entry对象时。添加一个新的entry对象，哈希冲突也是在这个函数里解决的。
return null;
}
void addEntry(int hash, K key, V value, int bucketIndex) {
Entry<K,V> e = table[bucketIndex];//把旧的链表地址临时保存在一个变量中
table[bucketIndex] = new Entry<K,V>(hash, key, value, e);//採用头插法。直接插到链表的头部
if (size++ >= threshold)
resize(2 * table.length);
}
如果我们要put两组数据，各自是put(0,0),put(10,10) ，如果计算哈希值的算法 int hash = key % 10; 那么0 和 10 的哈希值都为0，然后int i = indexFor(hash, table.length);
两组数据key相应的数组下标都是0。
那么是怎么插入的呢？先put(0,0)
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbGl1c2hlbmdiYW9ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
在put(10,10) 哈希冲突，在链表头部插入解决。
并发情况下HashMap的死循环问题
事实上HashMap本不该在并发环境下使用，应该考虑选择HashTable,ConcurrentHashMap。我们就来分析下HashMap的死循环问题。
当多个线程同一时候put数据的时候就有可能出现死循环的问题。
void addEntry(int hash, K key, V value, int bucketIndex) {
Entry<K,V> e = table[bucketIndex];//把旧的链表地址临时保存在一个变量中
table[bucketIndex] = new Entry<K,V>(hash, key, value, e);//採用头插法。直接插到链表的头部
if (size++ >= threshold)
resize(2 * table.length);//多线程下。多个线程可能会同一时候运行这个函数
}
void resize(int newCapacity) {
Entry[] oldTable = table;
int oldCapacity = oldTable.length;
if (oldCapacity == MAXIMUM_CAPACITY) {
threshold = Integer.MAX_VALUE;
return;
}
Entry[] newTable = new Entry[newCapacity];
transfer(newTable);//当2个线程同一时候运行这个转移数据到新的数组时就有可能出现故障。
table = newTable;
threshold = (int)(newCapacity * loadFactor);
}
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {//这个do while 循环要做的操作就是翻转旧的链表插入到新数组里面。
Entry<K,V> next = e.next;//标记1。如果线程1运行完这步
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
我们来个正常版的单线程环境下的resize操作，看图：
trasnfer(newTable)之前
trasnfer(newTable)完毕后
我们能够看出来。实际就是翻转链表插入到新容量的entry数组里面。
再来看看死循环版本号，有两个线程put数据都进行transfer(newTable) 操作，那么就会可能出现死循环。
当线程1 数据传输时，运行完了标记1的时候切换到了线程2，线程2运行了一次完整的翻转链表到新的entry数组时，线程1继续跑就会出现。
void transfer(Entry[] newTable) {
Entry[] src = table;
int newCapacity = newTable.length;
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {//这个do while 循环要做的操作就是翻转旧的链表插入到数组里面。
Entry<K,V> next = e.next;//标记1，如果线程1运行完这步
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
用图分析吧：
原数组：
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbGl1c2hlbmdiYW9ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
此时线程1运行到了标记1，然后切换到了线程2运行一个链表的翻转插入。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbGl1c2hlbmdiYW9ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
然后此时链表情况是这种。
watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbGl1c2hlbmdiYW9ibG9n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">
线程1在do while 里面就不断的循环 do (.....)while (e.next != null)，这样线程1就根本停不下来了。
HashSet
HashSet底层的存储结构是一个HashMap。HashSet 加入的每个值实际上就是在底层的HashMap里加入一个实体Entry<Key,Object> e,而这里的Object 事实上就是一个摆设。HashSet利用了HashMap的Key的唯一性，确保了在该数据结构中不会加入反复的值(保证了值的唯一性)。另外HashSet是同意插入null值的。依据HashSet的值的唯一性和高速加入的特性，我们能够想到，假设我们要高速加入大量的不能反复的元素到一个数据结构中，那么HashSet 是一个很好的选择。
HashTable
HashTable 跟HashMap 一样是一个存储键值对映射的数据结构，跟HashMap 不一样的是，HashTable 是线程安全的，HashTable 要插入的key 和 value 都不能为null。为啥不能为null呢？jdk文档里面说了。HashTable 是继承了字典的一种数据结构。我们能够在这样的字典里提高一个键值对以供查找。可是key 或者 value 不论什么一个都不能为null。
我是怎么觉得的呢？就像我们查字典一样。你总不能造个没有含义。没有表现的文字在字典里面吧，假设有我查到了，这是个null，没有含义，这全然违背了我们想通过查字典获取真相的初衷啊。
HashTable 的线程安全型是靠对每一个操作加锁的方式完毕的。
也就是锁住当前的HashTable实例对象。假设在并发大量的情况下。那么锁竞争会非常严重。我以为假设在并发情况不大的情况下当我们又想保证数据的并发安全性，我认为HashTable也是一种非常好的选择。
当然在并发量大的情况下。就优先选择ConcurrentHashMap 。
我自己写了个測试程序。在计数为2亿次的并发put測试中。不同线程数量。对HashTable 和 ConcurrentHashMap 的表现分析。
代码：
package hash_set_map_table; import java.util.Hashtable;
import java.util.Random;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger; public class HashThreadTask implements Runnable { static int TIME = 200000000;
//2个线程。并发put 200000000次，ConcurrentHashMap 31718 ms。Hashtable 35535 ms;
//20个线程，并发put 200000000次。ConcurrentHashMap 38732 ms，Hashtable 48357 ms;
//100个线程 并发put 200000000次，ConcurrentHashMap 36380 ms,Hashtable 46299 ms;
//200个线程 并发put 200000000次。ConcurrentHashMap 35801 ms, Hashtable 50579 ms;
private int threadId; public HashThreadTask(int threadId) {
this.threadId = threadId;
} public int getThreadId() {
return threadId;
} public void setThreadId(int threadId) {
this.threadId = threadId;
} static AtomicInteger count = new AtomicInteger(); public static Hashtable<Integer, Integer> getHashTableInstance() {
return TableHolder.table;
} public static ConcurrentHashMap<Integer, Integer> getConcurrentHashMap() {
return ConcurrentHashMapHolder.map;
} public static class TableHolder {
public static Hashtable<Integer, Integer> table = new Hashtable<Integer, Integer>();
} public static class ConcurrentHashMapHolder {
public static ConcurrentHashMap<Integer, Integer> map = new ConcurrentHashMap<Integer, Integer>();
} public static void main(String[] args) {
for (int i = 0; i < 200; i++) {//这里控制线程数量 測试数据依次为 2个线程。20个线程。100个线程。200个线程
HashThreadTask task = new HashThreadTask(i);
Thread thread = new Thread(task);
thread.start();
} long s = System.currentTimeMillis();
while (count.get() != TIME) {
}
System.out.println("cost time : "+ (System.currentTimeMillis() - s) + " count:" + count.get()); } public void run() {
// ConcurrentHashMap<Integer, Integer> container = getConcurrentHashMap();
Random random = new Random(System.currentTimeMillis());
Hashtable<Integer, Integer> container = getHashTableInstance();
do {
int old = count.get();
if (old < TIME) {
int i = random.nextInt(10000);
container.put(i, i);
count.compareAndSet(old, old+1);
}
}
while (count.get() < TIME); } }
结果:
//2个线程，并发put 200000000次，ConcurrentHashMap 31718 ms，Hashtable 35535 ms;
//20个线程，并发put 200000000次，ConcurrentHashMap 38732 ms，Hashtable 48357 ms;
//100个线程 并发put 200000000次。ConcurrentHashMap 36380 ms,Hashtable 46299 ms;
//200个线程 并发put 200000000次，ConcurrentHashMap 35801 ms, Hashtable 50579 ms;
在并发量不大的时候，当我们又想保证数据的并发安全性的话，我认为HashTable 优于 ConcurrentHashMap，由于Hashtable 没那么吃内存。
当在并发量大的时候，Hashtable 就输的一塌糊涂了。所以在这样的大并发环境下，我们我们不应该毫不犹豫的选择ConcurrentHashMap。