ConcurrentHashmap与hashmap的区别是，concurrentHashMap是线程安全的，而hashmap是线程不安全；
通过学习ConcurrentHashmap的源码，让我进一步了解了其结构；
下面请看里面最常用的put方法; 源码如下:
@SuppressWarnings("unchecked")
public V put(K key, V value) {
1 Segment<K,V> s;
2 if (value == null)
3 throw new NullPointerException();
4 int hash = hash(key);
5 int j = (hash >>> segmentShift) & segmentMask;
6 if ((s = (Segment<K,V>)UNSAFE.getObject // nonvolatile; recheck
7 (segments, (j << SSHIFT) + SBASE)) == null) // in ensureSegment
8 s = ensureSegment(j);
9 return s.put(key, hash, value, false);
}
第4行代码获取到hash;第8行代码，获取到这个map所对应的segment;第9行代码，将put操作交代segment去做；
接着继续跟跟足赛segment的put方法;
1 final V put(K key, int hash, V value, boolean onlyIfAbsent) {
2 HashEntry<K,V> node = tryLock() ? null :
3 scanAndLockForPut(key, hash, value);
4 V oldValue;
5 try {
6 HashEntry<K,V>[] tab = table;
7 int index = (tab.length - 1) & hash;
8 HashEntry<K,V> first = entryAt(tab, index);
9 for (HashEntry<K,V> e = first;;) {
10 if (e != null) {
11 K k;
12 if ((k = e.key) == key ||
13 (e.hash == hash && key.equals(k))) {
14 oldValue = e.value;
15 if (!onlyIfAbsent) {
16 e.value = value;
17 ++modCount;
18 }
19 break;
20 }
21 e = e.next;
22 }
23 else {
24 if (node != null)
25 node.setNext(first);
26 else
27 node = new HashEntry<K,V>(hash, key, value, first);
28 int c = count + 1;
29 if (c > threshold && tab.length < MAXIMUM_CAPACITY)
30 rehash(node);
31 else
32 setEntryAt(tab, index, node);
33 ++modCount;
34 count = c;
35 oldValue = null;
36 break;
37 }
38 }
39 } finally {
40 unlock();
41 }
42 return oldValue;
43 }
第1行代码:final代表方法不可被重写。第3行代码给整块代码段加锁；
第9行到39行代码执行业务代码，也就是进行put操作所要进行的，地址修改；由于我们现在研究的重点是加锁方式，
所以我们加锁的方法scanAndLockForPut;方法如下:
private HashEntry<K,V> scanAndLockForPut(K key, int hash, V value) {
1 HashEntry<K,V> first = entryForHash(this, hash);
2 HashEntry<K,V> e = first;
3 HashEntry<K,V> node = null;
4 int retries = -1; // negative while locating node
5 while (!tryLock()) {
6 HashEntry<K,V> f; // to recheck first below
7 if (retries < 0) {
8 if (e == null) {
9 if (node == null) // speculatively create node
10 node = new HashEntry<K,V>(hash, key, value, null);
11 retries = 0;
12 }
13 else if (key.equals(e.key))
14 retries = 0;
15 else
16 e = e.next;
17 }
18 else if (++retries > MAX_SCAN_RETRIES) {
19 lock();
20 break;
21 }
22 else if ((retries & 1) == 0 &&
23 (f = entryForHash(this, hash)) != first) {
24 e = first = f; // re-traverse if entry changed
25 retries = -1;
26 }
27 }
28 return node;
29 }
第5行代码tryLock跟踪
1 public boolean tryLock() {
2 return sync.nonfairTryAcquire(1);
}
第2行代码跟踪，此处为非公平锁；
1 final boolean nonfairTryAcquire(int acquires) {
2 final Thread current = Thread.currentThread();
3 int c = getState();
4 if (c == 0) {
5 if (compareAndSetState(0, acquires)) {
6 setExclusiveOwnerThread(current);
7 return true;
8 }
9 }
10 else if (current == getExclusiveOwnerThread()) {
11 int nextc = c + acquires;
12 if (nextc < 0) // overflow
13 throw new Error("Maximum lock count exceeded");
14 setState(nextc);
15 return true;
16 }
17 return false;
18 }
此段代码不做分析；网上查了一下非公平锁与公平锁的区别，引用如下
"
在公平的锁上，线程按照他们发出请求的顺序获取锁，但在非公平锁上，则允许‘插队’：当一个线程请求非公平锁时，如果在发出请求的同时该锁变成可用状态，那么这个线程会跳过队列中所有的等待线程而获得锁。 非公平的ReentrantLock 并不提倡 插队行为，但是无法防止某个线程在合适的时候进行插队。
在公平的锁中，如果有另一个线程持有锁或者有其他线程在等待队列中等待这个所，那么新发出的请求的线程将被放入到队列中。而非公平锁上，只有当锁被某个线程持有时，新发出请求的线程才会被放入队列中。
非公平锁性能高于公平锁性能的原因：
在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。
假设线程A持有一个锁，并且线程B请求这个锁。由于锁被A持有，因此B将被挂起。当A释放锁时，B将被唤醒，因此B会再次尝试获取这个锁。与此同时，如果线程C也请求这个锁，那么C很可能会在B被完全唤醒之前获得、使用以及释放这个锁。这样就是一种双赢的局面：B获得锁的时刻并没有推迟，C更早的获得了锁，并且吞吐量也提高了。
当持有锁的时间相对较长或者请求锁的平均时间间隔较长，应该使用公平锁。在这些情况下，插队带来的吞吐量提升（当锁处于可用状态时，线程却还处于被唤醒的过程中）可能不会出现。
"可以理解为非公平锁的性能更高一些；
也就是说ConcurrenthashMap是利用可重入锁里面的非公平锁来给segment加上锁的；
针对concurrentHashmap的数据结构，我查阅相关资料，如下：
如上所示:concurrentHashmap锁住的颗粒度更小，针对segment进行锁;
对concurrentHashMap的分析到此为止，确有许多代码细节，我还没有看明白，后面搞清楚了再研究欢迎扔砖。