线程传递增强之TransmittableThreadLocal

先来看TTL里面的几个重要属性及方法 TTL定义: public class TransmittableThreadLocal extends InheritableThreadLocal 可以看到,TTL继承了ITL,意味着TTL首先具备ITL的功能。 再来看看一个重要属性holder: /** * 这是一个ITL类型的对象,持有一个全局的WeakMap(weakMap的key是弱引用,同TL一样,也是为了解决内存泄漏的问题),里面存放了TTL对象 * 并且重写了initialValue和childValue方法,尤其是childValue,可以看到在即将异步时父线程的属性是直接作为初始化值赋值给子线程的本地变量对象(TTL)的 */ private static InheritableThreadLocal<Map<TransmittableThreadLocal<?

生产-消费模型之虚假唤醒

1 何为虚假唤醒 当线程从等待状态中被唤醒时,只是发现未满足其正在等待的条件时,就会发生虚假唤醒。 之所以称其为虚假的,是因为该线程似乎无缘无故被唤醒。 虚假唤醒不会无缘无故发生,通常是因为在发起唤醒号和等待线程最终运行之间的临界时间内,线程不再满足竞态条件。 2 java中的例子 public class SpuriousWakeupRWLock { private static final CustomQueue CUSTOM_LIST = new CustomQueue(); public static void main(String[] args) throws Exception { for (int i = 0; i < 8; i++) { Thread consumer = new Thread(() -> { try { CUSTOM_LIST.

并发基础之Condition(等待队列)

1 定义 Condition是在AQS中配合使用的wait/nofity线程通信协调工具类,我们可以称之为等待队列 Condition定义了等待/通知两种类型的方法,当前线程调用这些方法时,需要提前获取到Condition对象关联的锁。Condition对象是调用Lock对象的newCondition()方法创建出来的,换句话说,Condition是依赖Lock对象。 Condition与Object中监视器方法不同点 >condition可以有多个等待队列 monitor只有一个队列在对象头中 condition的等待可以自定义超时时间 conditon的signal 是唤醒等待队列头部的线程节点, Object的notify是随机唤醒 condition对象的属性对开发者透明 2 Condition使用 demo代码如下

并发基础之AQS同步器(二)

在AQS同步器组件原理分析前,我们需要了解同步队列这个概念,了解同步队列中节点的入队和出队的流程,CHL同步队列的由来,可以参考我之前的文章: 并发基础之AQS同步器(一) 1 同步队列 同步器依赖内部的同步队列(一个FIFO双向队列)来完成同步状态的管理,当前线程获取同步状态失败时,同步器会将当前线程以及等待状态等信息构造成为一个节点(Node)并将其加入同步队列,同时会阻塞当前线程,当同步状态释放时,会把首节点中的线程唤醒,使其再次尝试获取同步状态 FIFO队列Node对象的具体实现如下: static final class Node { static final Node SHARED = new Node(); static final Node EXCLUSIVE = null; static final int CANCELLED = 1; static final int SIGNAL = -1; static final int CONDITION = -2; static final int PROPAGATE = -3; volatile int waitStatus; volatile Node prev; volatile Node next; volatile Thread thread; Node nextWaiter; .

并发基础之AQS同步器(一)

1 AQS同步器 队列同步器AbstractQueuedSynchronizer,是用来构建锁或者其他同步组件的基础框架,它使用了一个int成员变量表示同步状态,通过内置的FIFO队列来完成资源获取线程的排队工作,并发包的作者(Doug Lea)期望它能够成为实现大部分同步需求的基础。 同步器的主要使用方式是继承,子类通过继承同步器并实现它的抽象方法来管理同步状态,在抽象方法的实现过程中免不了要对同步状态进行更改,这时就需要使用同步器提供的3个方法 >getState() setState(int newState) compareAndSetState(int expect,int update) 来进行操作,因为它们能够保证状态的改变是安全的。这样就可以方便实现不同类型的同步组件(ReentrantLock、ReentrantReadWriteLock和CountDownLatch等) 核心操作方式: 场景1:阻塞直到获取指定资源数

synchronized实现原理及锁优化

1.引言 并发编程中synchronized是重量级锁,但随着JVM1.6对synchronized进行优化后,有些情况下它并不那么重,本文介绍了Java SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁,以及锁的存储结构和升级过程。 2.术语定义 CAS(Compare and Swap): 比较并交换。用于在硬件层面上提供原子性操作。在 Intel 处理器中,比较并交换通过指令cmpxchg实现。比较是否和给定的数值一致,如果一致则修改,不一致则不修改。 3.同步的基础 Java中的每一个对象都可以作为锁。 对于同步方法,锁是当前实例对象。 对于静态同步方法,锁是当前对象的Class对象。 对于同步方法块,锁是synchonized括号里配置的对象。

JUC知识点总结

作为并发的基础,我们需要熟悉掌握JUC相关的知识,才能更好的在实际项目中运用, 下面是整理出来的juc思维导图: #系列文章 java内存模型之[JMM][重排序][happens-before] volatile关键字原理实现及应用 synchronized实现原理及锁优化 =============不定期更新============================

volatile关键字原理实现及应用

1.并发编程中的三个概念 在并发编程中, 需要了解线程的三个概念:原子性,可见性,有序性: 1.1.原子性 原子性:即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断,要么就都不执行。 一个很经典的例子就是银行账户转账问题: 比如从账户A向账户B转1000元,那么必然包括2个操作:从账户A减去1000元,往账户B加上1000元。 试想一下,如果这2个操作不具备原子性,会造成什么样的后果。假如从账户A减去1000元之后,操作突然中止。然后又从B取出了500元,取出500元之后, 再执行 往账户B加上1000元 的操作。这样就会导致账户A虽然减去了1000元,但是账户B没有收到这个转过来的1000元。 所以这2个操作必须要具备原子性才能保证不出现一些意外的问题。  同样地反映到并发编程中会出现什么结果呢?

java内存模型之[JMM][重排序][happens-before]

1.并发编程模型的分类 在并发编程中,我们需要处理两个关键问题:线程之间如何通信及线程之间如何同 步(这里的线程是指并发执行的活动实体)。通信是指线程之间以何种机制来交换 信息。在命令式编程中,线程之间的通信机制有两种:*共享内存和消息传递*。 在共享内存的并发模型里,线程之间共享程序的公共状态,线程之间通过写-读内 存中的公共状态来隐式进行通信。在消息传递的并发模型里,线程之间没有公共状 态,线程之间必须通过明确的发送消息来显式进行通信。 同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模 型里,同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之 间互斥执行。在消息传递的并发模型里,由于消息的发送必须在消息的接收之前, 因此同步是隐式进行的。 Java 的并发采用的是共享内存模型,Java 线程之间的通信总是隐式进行,整个通 信过程对程序员完全透明。如果编写多线程程序的 Java 程序员不理解隐式进行的 线程之间通信的工作机制,很可能会遇到各种奇怪的内存可见性问题。

可重入锁

可重入锁,也叫做递归锁,指的是同一线程 外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码,但不受影响。比如ReentrantLock 和synchronized 都是 可重入锁 直接放代码 public class SubService { ReentrantLock lock = new ReentrantLock(); public void subService1() { lock.