JUC初始整理

涉及JUC 并发包的 均涉及对共享变量的操作 并发 懂得啥叫并发不 以下所阐述的东西均来自于并发环境

一.CAS：举例（原子操作 使用AtomicInteger getAndIncrement()）
简述过程：从主内存中拿出并交换

​ 弊端：开销
​ 仅能对一个共享变量操作
​ ABA问题

​ 源码:

二.ABA：问题简述：在CAS的基础上（从主内存拿到数据—>工作内从相比较过程中（时间差），可能会导致数据变化（将value 置为2 又置为1））

​ 解决：AtomicReference原子引用：类似于时间戳，增加一种版本号

三.ArrayList在多线程下的问题：
1.出现并发修改异常：ConcurrentModificationException
2.解决方式
Vector(+了锁，数据一致性得到保障，并发性↓)
Collections.synchronizedList(new ArrayList<>())
CopyOnWriteArrayList Arrays.copyOf() 拷贝数据到新【容器】 最后再将引用指向新容器

四.锁

公平锁
非公平锁：直接尝试占有锁，尝试失败，则采用类似于公平锁的那种方式到等待队列中进行等待，按照FIFO的规则获取锁 synchronized为非公平锁，RetrantLock构造函数可指定是否公平，默认false

可重入锁：线程可进入他所持有的锁的同步着的代码块（synchronized reentrantlock）

​ EG及现象 进了家大门占有锁 房间的门不用钥匙解锁直接进

自旋锁：尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁

​ 好处：不会阻塞，减少上下文切换的消耗
​ 坏处：循环尝试获取锁，消耗cpu

​ EG及现象 去办公室找老师，老师在打电话，重复来办公室多次来判断老师打没打完电话

独占锁：鼠标只能由一个人操作：该锁一次只能被一个线程持有

共享锁：屏幕可由多个人观看：改锁一次可被多个线程所持有

互斥锁：写写读读，读读写写即互斥：共享读，独占写
为什么会出现ReentrantReadWriteLock？ readLock().lock writeLock().lock()
–A：对于synchronized与lock而言，只要拿到了锁，不管是读还是写，别的线程不能动
此时有一种场景，签名，有人在看，有人在写，既保证了数据的一致性，又保证了并发性

​ 机场大屏，可由多个乘客看到，仅能由一个工作人员修改

countdownlatch 倒计时

cyclicbarrier 循环屏障

synchronized与lock区别

s属于jvm层面
lock属于api层面

s 非公平锁
l 由构造方法传入true/false来控制是否公平

s执行过程中除非有异常或者执行完成才可中断
l可中断 trylock设置超时时间 或 interrupt方法