1.1

锁分为无锁、偏向锁、轻量级锁、重量级锁状态。

会根据情况进行依次升级。

1.2.1

“偏向锁的标记”记录这个锁属于哪个线程。

如果后续没有其他线程来竞争该锁那么就不用进行其他同步操作了避免了加锁解锁的开销。

如果后续有其他线程来竞争该锁刚才已经在锁对象中记录了当前锁属于哪个线程了很容易识别当前申请锁的线程是不是之前记录的线程那就取消原来的偏向锁状态进入一般的轻量级锁状态。

偏向锁本质上相当于

“延迟加锁”。

能不加锁就不加锁尽量来避免不必要的加锁开销。

但是该做的标记还是得做的否则无法区分何时需要真正加锁。

1.2.2

随着其他线程进入竞争偏向锁状态被消除进入轻量级锁状态自适应的自旋锁。

此处的轻量级锁就是通过

CAS

该线程引用如果更新成功则认为加锁成功如果更新失败则认为锁被占用继续自旋式的等待并不放弃CPU。

CPU

如果竞争进一步激烈自旋不能快速获取到锁状态就会膨胀为重量级锁。

此处的重量级锁就是指用到内核提供的

mutex

执行加锁操作先进入内核态在内核态判定当前锁是否已经被占用如果该锁没有占用则加锁成功并切换回用户态如果该锁被占用则加锁失败。

此时线程进入锁的等待队列挂起等待被操作系统唤醒。

经历了一系列的沧海桑田这个锁被其他线程释放了操作系统也想起了这个被挂起的线程于是唤醒这个线程尝试重新获取锁。

1.3

的调用都会涉及加锁和解锁但如果只是在单线程中执行这个代码那么这些加锁解锁操作是没有必要的白白浪费了一些资源开销。

1.4

锁粗化这里涉及一个概念粒度不是力度加锁的范围内包含代码的多少包含的代码越多就认为锁的粒度就越粗反之锁的粒度就越细。

的策略是比较复杂的在背后做了很多事情目的为了让程序猿哪怕啥都不懂也不至于写出特别慢的程序。

JVM

Java

答偏向锁不是真的加锁而只是在锁的对象头中记录⼀个标记(记录该锁所属的线程)。

如果没有其他线程参与竞争锁那么就不会真正执行加锁操作从而降低程序开销。

⼀旦真的涉及到其他的线程竞争再取消偏向锁状态进入轻量级锁状态。

synchronized

答刚开始是一个标记遇到所冲突升级成轻量级锁采用自旋锁的方式实现随着锁冲突的升级锁升级为重量级锁采用挂起等待锁的方式来实现锁。

java.util.concurrent

“返回值”。

方便程序猿借助多线程的方式计算结果。

可以认为是一个带返回参数的

runnable

往往是在另⼀个线程中执行的啥时候执行完并不确定。

FutureTask

futureTask.get()线程还没执行完毕就会阻塞等待。

FutureTask

我们可以将它们的关系理解成吃麻辣烫的情形去吃麻辣烫Callable

call

FutureTask后面我们可以随时凭这张小票去查看自己的这份麻辣烫做出来了没有线程是否执行完毕。

演示案例创建线程计算

FutureTask(callable);//小票Thread

new

Thread(futureTask);//后厨t1.start();//后厨开始工作t1.join();System.out.println(futureTask.get());//小票取餐}

}案例演示效果如下

lock()加锁如果获取不到锁就死等。

trylock(超时时间)加锁如果获取不到锁等待⼀定的时间之后就放弃加锁。

unlock()解锁。

synchronized

实现等待-唤醒。

每次唤醒的是一个随机等待的线程。

ReentrantLock

Condition

synchronized效率更高自动释放更方便。

锁竞争激烈的时候使用

ReentrantLock搭配

100个可用资源。

当有车开进去的时候就相当于申请一个可用资源可用车位就

Semaphore

{semaphore.acquire();System.out.println(Thread.currentThread().getName()

获取到资源);}

RuntimeException(e);}System.out.println(Thread.currentThread().getName()

释放资源);semaphore.release();}};Thread

new

Thread(runnable);t1.start();t2.start();}

}案例演示结果如下

当我们把一个任务拆分成很多个的时候可以通过这个工具类来识别任务是否整体执行完毕了。

CountDownLatch

内部的计数器同时自减主线程中使用latch.await();阻塞等待。

所有任务执行完毕相当于计数器为

案例演示

java.util.concurrent.CountDownLatch;

public

RuntimeException(e);}System.out.println(Thread.currentThread().getName()

执行完毕);latch.countDown();}};Thread

new

Thread(runnable);t1.start();t2.start();latch.await();System.out.println(Main

线程执行完毕);}

原来的集合类大部分都不是线程安全的。

VectorStackHashTable是线程安全的(不建议用)其他的集合类不是线程安全的。

3.1

Collections.synchronizedListnew

synchronized

CopyOnWriteArrayList当我们往一个容器中添加元素的时候不直接往当前容器添加而是先将当前容器进行

Copy复制出一个新的容器然后在新的容器里面添加元素添加完元素之后再将原容器的引用指向新的容器。

CopyOnWrite

容器进行并发的读而不需要加锁因为当前容器不会添加任何元素。

所以

CopyOnWrite

LinkedBlockingQueue基于链表实现的阻塞队列。

PriorityBlockingQueue基于堆实现的带优先级的阻塞队列。

3.3

本身不是线程安全的。

在多线程环境下使用哈希表可以使用Hashtable不推荐使用ConcurrentHashMap推荐使用这个。

3.3.1

⼀旦触发扩容就由该线程完成整个扩容过程。

这个过程会涉及到大量的元素拷贝效率会非常低。

3.3.2

发现需要扩容的线程只需要创建⼀个新的数组同时只搬几个元素过去。

扩容期间新老数组同时存在。

后续每个来操作

ConcurrentHashMap

的线程都会参与搬家的过程。

每个操作负责搬运一小部分元素。

搬完最后一个元素再把老数组删掉。

这个期间插入只往新数组中加。

这个期间查找需要同时查新数组和老数组。

其实写博客不仅仅是为了教大家同时这也有利于我巩固知识点和做一个学习的总结由于作者水平有限对文章有任何问题还请指出非常感谢。

如果大家有所收获的话还请不要吝啬你们的点赞收藏和关注这可以激励我写出更加优秀的文章。