1.synchronized之错误的加锁和原因分析
-
锁一定要加在一个不变的对象上
-
volatile 关键字，最轻量的同步机制
volatile 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某 个变量的值，这新值对其他线程来说是立即可见的。
可以保证可见，但是不能保证原子
volatile 最适用的场景：一个线程写，多个线程读。
2.ThreadLocal辨析
ThreadLocal 为每个线程都提供了变量的副本，使得每个线程在某一时间訪问到的并非同一个对象，这样就隔离了多个线程对数据的数据共享
- void set(Object value) 设置当前线程的线程局部变量的值。
- public Object get() 该方法返回当前线程所对应的线程局部变量。
- public void remove() 将当前线程局部变量的值删除，目的是为了减少内存的占用。
- protected Object initialValue()返回该线程局部变量的初始值，该方法是一个 protected 的方法，显然是为 了让子类覆盖而设计的。
ThreadLocal辨析
每个线程独有的 ThreadLocalMap 然后再用 ThreadLocal 的当前实例，拿到 Map 中的相应的 Entry，然后就可 以拿到相应的值返回出去。当然，如果 Map 为空，还会先进行map 的创建，初始化等工作。
-
ThreadLocal可能会产生内存泄漏
图中的虚线表示弱引用。
这样，当把 threadlocal 变量置为 null 以后，没有任何强引用指向 threadlocal 实例，所以 threadlocal 将会被 gc 回收。这样一来，ThreadLocalMap 中就会出现 key 为 null 的 Entry，就没有办法访问这些 key 为 null 的 Entry 的 value，如果当前 线程再迟迟不结束的话，这些 key 为 null 的 Entry 的 value 就会一直存在一条强 引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value，而这块 value 永 远不会被访问到了，所以存在着内存泄露。
ThreadLocal 内存泄漏的根源是：由于 ThreadLocalMap 的生命周期跟 Thread 一样长，如果没有手动删除对应 key 就会导致内存泄漏，而不是因为弱引 用。总结 JVM 利用设置 ThreadLocalMap 的 Key 为弱引用，来避免内存泄露。 JVM 利用调用 remove、get、set 方法的时候，回收弱引用。 当 ThreadLocal 存储很多 Key 为 null 的 Entry 的时候，而不再去调用 remove、 get、set 方法，那么将导致内存泄漏。 使用线程池+ ThreadLocal 时要小心，因为这种情况下，线程是一直在不断的 重复运行的，从而也就造成了 value 可能造成累积的情况。
- ThreadLocal线程不安全的情况
每个线程中的 ThreadLocal 都应该持有一个新的 Number 对象。
3.线程之间的协作
-
等待和通知
wait():调用该方法的线程进入 WAITING 状态,只有等待另外线程的通知或被中断 才会返回.需要注意,调用 wait()方法后,会释放对象的锁
notify/notifyAll
通知一个在对象上等待的线程,使其从 wait 方法返回,而返回的前提是该线程 获取到了对象的锁，没有获得锁的线程重新进入 WAITING 状态。 -
等待和通知的标准范式
等待方遵循如下原则。
1）获取对象的锁。
2）如果条件不满足，那么调用对象的 wait()方法，被通知后仍要检查条件。
3）条件满足则执行对应的逻辑。
通知方遵循如下原则。
1）获得对象的锁。
2）改变条件。
3）通知所有等待在对象上的线程。
-
notify 和 notifyAll 应该用谁 尽可能用 notifyall()，谨慎使用 notify()，因为 notify()只会唤醒一个线程，我 们无法确保被唤醒的这个线程一定就是我们需要唤醒的线程
-
调用 yield() 、sleep()、wait()、notify()等方法对锁有何影响？
yield() 、sleep()被调用后，都不会释放当前线程所持有的锁。 调用 wait()方法后，会释放当前线程持有的锁，而且当前被唤醒后，会重新 去竞争锁，锁竞争到后才会执行 wait 方法后面的代码。 调用 notify()系列方法后，对锁无影响，线程只有在 syn 同步代码执行完后才 会自然而然的释放锁，所以 notify()系列方法一般都是 syn 同步代码的最后一行。
4.线程的并发工具类
-
Fork-Join（分而治之的算法）
Fork-Join原理
-
工作密取
当前线程的 Task 已经全被执行完毕，则自动取到其他线程的 Task 池中取 出 Task 继续执行。
工作密取
-
Fork/Join 使用的标准范式
Fork/Join 使用的标准范式
-
CountDownLatch(闭锁)
闭锁，CountDownLatch 这个类能够使一个线程等待其他线程完成各自的工 作后再执行。例如，应用程序的主线程希望在负责启动框架服务的线程已经启动 所有的框架服务之后再执行。
CountDownLatch 是通过一个计数器来实现的，计数器的初始值为初始任务 的数量。每当完成了一个任务后，计数器的值就会减 1 （CountDownLatch.countDown()方法）。当计数器值到达 0 时，它表示所有的已 经完成了任务，然后在闭锁上等待 CountDownLatch.await()方法的线程就可以恢 复执行任务。 -
CyclicBarrier
会让所有线程都等待完成后才会继续下一步行动 -
Semaphore
Semaphore 通常我们叫它信号量， 可以用来控制同时访问特定资源的线程数量，通过协调各个线程，以保证合理的使用资源。 -
Exchange
Exchange位于java.util.concurrent包下面，主要是用于线程之间数据交换的工具类，经常用于管道设计和遗传算法中
6.线程的状态
- 初始（new）
- 运行中（running）
- 就绪（ready）
- 等待（waiting）
- 等待超时（timed_waiting）
- 终止（terminated）
- 阻塞（blocked）
线程的状态
- 死锁
死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。
产生条件：
1.多个操作者争夺多个资源
2.争夺资源的顺序不对
3.拿到资源不放手
学术说法：
1.互斥条件
2.请求和保持
3.不剥夺
4.环路等待
-
活锁
两个线程在尝试拿锁的机制中，发生多个线程之间互相谦让，不断发生同一个线程总是拿到同一把锁，在尝试拿另一把锁时因为拿不到，而将本来已经持有的锁释放的过程。
解决办法：每个线程休眠随机数，错开拿锁的时间。 -
线程饥饿
低优先级的线程，总是拿不到执行时间
7.CAS（Compare And Swap）
-
什么是原子操作？如何实现原子操作？
假定有两个操作A和B(A和B可能都很复杂)，如果从执行A的线程来看，当另一个线程执行B时，要么将B全部执行完，要么完全不执行B，那么A和B对彼此来说是原子的。
synchronized关键字是基于阻塞的锁机制，也就是说当一个线程拥有锁的时候，访问同一资源的其它线程需要等待，直到该线程释放锁 -
CAS原理
基本思路就是，如果这个地址上的值和期望的值相等，则给其赋予新值，否则不做任何事儿，但是要返回原值是多少。循环CAS就是在一个循环里不断的做cas操作，直到成功为止。
synchronized 悲观锁
CAS 乐观锁
-
CAS的问题
1.ABA问题
因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。
ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加1，那么A→B→A就会变成1A→2B→3A。
2.循环时间长开销大。
自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。
3.只能保证一个共享变量的原子操作。 -
Jdk中相关原子操作类的使用
更新基本类型类：AtomicBoolean，AtomicInteger，AtomicLong
更新数组类：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray
更新引用类型：AtomicReference，AtomicMarkableReference，AtomicStampedReference
网友评论