1：ConcorrenctHashMap 分段锁
HashMap ：先说HashMap，HashMap是线程不安全的，在并发环境下，可能会形成环状链表（扩容时可能造成，具体原因自行百度google或查看源码分析），导致get操作时，cpu空转，所以，在并发环境中使用HashMap是非常危险的。
HashTable ： HashTable和HashMap的实现原理几乎一样，差别无非是1.HashTable不允许key和value为null；2.HashTable是线程安全的。但是HashTable线程安全的策略实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁，多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。
首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问
ConcurrentHashMap是由Segment数组结构和HashEntry数组结构组成，Segment是一种可重入锁ReentrantLock
get操作不需要锁。
除非读到的值是空的才会加锁重读，我们知道HashTable容器的get方法是需要加锁的，那么ConcurrentHashMap的get操作是如何做到不加锁的呢？原因是它的get方法里将要使用的共享变量都定义成volatile
Put方法 1.定位segment并确保定位的Segment已初始化 2.调用Segment的put方法。
get方法无需加锁，由于其中涉及到的共享变量都使用volatile修饰，volatile可以保证内存可见性，所以不会读取到过期数据。
每一个 Segment 对象都有一个 count 对象来表示本 Segment 中包含的 HashEntry 对象的总数。注意，之所以在每个 Segment 对象中包含一个计数器，而不是在 ConcurrentHashMap 中使用全局的计数器，是为了避免出现“热点域”而影响 ConcurrentHashMap 的并发性。
ConcurrentHashMap 在默认并发级别会创建包含 16 个 Segment 对象的数组
在 ConcurrentHashMap 中，不允许用 null 作为键和值
Romove 操作一样，首先根据散列码找到具体的链表；然后遍历这个链表找到要删除的节点；最后把待删除节点之后的所有节点原样保留在新链表中，把待删除节点之前的每个节点克隆到新链表中。
写线程对某个链表的结构性修改不会影响其他的并发读线程对这个链表的遍历访问。
ConcurrentHashMap 的高并发性主要来自于三个方面：
1.用分离锁实现多个线程间的更深层次的共享访问。
2.用 HashEntery 对象的不变性来降低执行读操作的线程在遍历链表期间对加锁的需求。
3.通过对同一个 Volatile 变量的写 / 读访问，协调不同线程间读 / 写操作的内存可见性。
ConcurrentSkipListMap
ConcurrentSkipListMap提供了一种线程安全的并发访问的排序映射表。内部是SkipList（跳表）结构实现，在理论上能够在O(log(n))时间内完成查找、插入、删除操作。
注意，调用ConcurrentSkipListMap的size时，由于多个线程可以同时对映射表进行操作，所以映射表需要遍历整个链表才能返回元素个数，这个操作是个O(log(n))的操作
Skip list的性质
(1)由很多层结构组成，level是通过一定的概率随机产生的。
(2) 每一层都是一个有序的链表，默认是升序，也可以根据创建映射时所提供的Comparator进行排序，具体取决于使用的构造方法。
(3) 最底层(Level 1)的链表包含所有元素。
(4) 如果一个元素出现在Level i 的链表中，则它在Level i 之下的链表也都会出现。
(5) 每个节点包含两个指针，一个指向同一链表中的下一个元素，一个指向下面一层的元素。
2：CopyOnWriteArrayList
CopyOnWrite并发容器用于读多写少的并发场景，线程安全的 写时复制
CopyOnWrite容器有很多优点，但是同时也存在两个问题，即内存占用问题和数据一致性问题
由于所有的写操作都是在新数组进行的，这个时候如果有线程并发的写，则通过锁来控制，如果有线程并发的读，则分几种情况：
1、如果写操作未完成，那么直接读取原数组的数据；
2、如果写操作完成，但是引用还未指向新数组，那么也是读取原数组数据；
3、如果写操作完成，并且引用已经指向了新的数组，那么直接从新数组中读取数据。
可见，CopyOnWriteArrayList的读操作是可以不用加锁的。
3：ReentrantLock（可重入锁）
效果和synchronized一样，都可以同步执行，lock方法获得锁，unlock方法释放锁
ReentrantLock的默认实现为非公平锁
Synchronized与ReetrantLockqubie
Synchronized的锁获取和释放都是由jvm执行的
Synchronized它无法中断一个正在等候获得锁的线程，也无法通过投票得到锁，如果不想等下去，也就没法得到锁
ReetrantLockqubie添加了类似锁投票、定时锁等候和可中断锁等候的一些特性
争用下的 ReentrantLock 实现更具可伸缩性
支持公平锁
同一个线程可以多次获取同一把锁。ReentrantLock和synchronized都是可重入锁。
可中断锁。可中断锁是指线程尝试获取锁的过程中，是否可以响应中断。synchronized是不可中断锁，而ReentrantLock则提供了中断功能。
公平锁与非公平锁。公平锁是指多个线程同时尝试获取同一把锁时，获取锁的顺序按照线程达到的顺序，而非公平锁则允许线程“插队”。synchronized是非公平锁，而ReentrantLock的默认实现是非公平锁，但是也可以设置为公平锁。
AbstractQueuedSynchronizer简称AQS，是一个用于构建锁和同步容器的框架
4：ReentrantReadWriteLock
ReentrantLock是一个排他锁，同一时间只允许一个线程访问，而ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问
ReentrantReadWriteLock支持以下功能：
1）支持公平和非公平的获取锁的方式；
2）支持可重入。读线程在获取了读锁后还可以获取读锁；写线程在获取了写锁之后既可以再次获取写锁又可以获取读锁；
3）还允许从写入锁降级为读取锁，其实现方式是：先获取写入锁，然后获取读取锁，最后释放写入锁。但是，从读取锁升级到写入锁是不允许的；
4）读取锁和写入锁都支持锁获取期间的中断；
5）Condition支持。仅写入锁提供了一个 Conditon 实现；读取锁不支持 Conditon ，readLock().newCondition() 会抛出 UnsupportedOperationException
5：CyclicBarrier 循环栅栏
public CyclicBarrier(int parties)
public CyclicBarrier(int parties, Runnable barrierAction)
参数parties指定线程数量，当指定的线程值都到达栅栏点时，栅栏打开，线程恢复
是一个同步工具类，它允许一组线程在到达某个栅栏点(common barrier point)互相等待，发生阻塞，直到最后一个线程到达栅栏点，栅栏才会打开，处于阻塞状态的线程恢复继续执行.它非常适用于一组线程之间必需经常互相等待的情况。
6：CountDownLatch
CountDownLatch类位于java.util.concurrent包下，利用它可以实现类似计数器的功能。比如有一个任务A，它要等待其他4个任务执行完毕之后才能执行，此时就可以利用CountDownLatch来实现这种功能了
7：Semaphore 信号量
它负责协调各个线程, 以保证它们能够正确、合理的使用公共资源。
Semaphore可以控制某个资源可被同时访问的个数，通过 acquire() 获取一个许可，如果没有就等待，而 release() 释放一个许可
对资源的保护。
CountDownLatch和CyclicBarrier都能够实现线程之间的等待，只不过它们侧重点不同：
CountDownLatch一般用于某个线程A等待若干个其他线程执行完任务之后，它才执行；
而CyclicBarrier一般用于一组线程互相等待至某个状态，然后这一组线程再同时执行；
另外，CountDownLatch是不能够重用的，而CyclicBarrier是可以重用的。
2）Semaphore其实和锁有点类似，它一般用于控制对某组资源的访问权限。
8：Exchanger
Exchanger可以在两个线程之间交换数据，只能是2个线程，他不支持更多的线程之间互换数据。
9：Future Future用来得到返回值。
Callable接口可以看作是Runnable接口的补充，call方法带有返回值，并且可以抛出异常
runnable接口实现的没有返回值的并发编程。
callable实现的存在返回值的并发编程。（call的返回值String受泛型的影响）
同样是callable，使用Future获取返回值。
扫一扫
2794
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
