保暖透气大裤衩LeoLee的博客

初始化ConcurrentHashMap<String, Object> cMap = new ConcurrentHashMap<>();默认的构造方法中是空方法，数组的长度默认是16，在第一次put操作的时候进行数组的初始化。/** * Creates a new, empty map with the default initial table size (16). */public ConcurrentHashMap() {}但是在实际的使用中，如

概述最初接触BlockingQueue肯定是通过Java的线程池ThreadPoolExecutor的，在使用Executors创建四种线程池的时候，默认帮我制定了使用的BlockingQueue，如下： public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE,

概述

概述ReentrantReadWriteLock，是一种读写锁，对读写操作的多线程访问提供了特殊处理，可以提高读取操作的性能，让读并发，写加锁。读操作可并发 读写操作互斥 写操作互斥其原理与ReentrantLock基本一直，只不过加入了读写锁的逻辑，底层也是使用了AQS同步器，AQS的源码解析可查阅我的另一篇文章：Java多线程——JUC之AQS（AbstractQueuedSynchronizer）分析，ReentrantLock的实现原理解析基本使用package com.le

概述AQS是用来构建锁或者其他同步器组件的重要基础框架，是JUC体系的基石。通过内置的FIFO（先进先出队列，CLH队列，是一个单向链表，AQS的队列是CLH的一个变体，虚拟的双向FIFO）队列来完成资源获取线程的排队工作，并通过一个int类型的变量表示持有锁的状态。ReentrantLock、ReentrantReadWriteLock、CountDownLatch、Semaphore等底层都是存在一个内部类继承了AbstractQueuedSynchronizer，为这些具体的并发工具提供了一种排队

概述也是刚接触ForkJoin，简单记录一下，纯属初体验。Fork/Join是JDK1.7加入的新的线程池实现，其体现的是一种分治思想，适用于能够进行任务拆分的CPU密集型运算（默认创建与CPU核心数相同大小的线程池，由于是CPU密集型运算，线程池大小超过CPU核心数没有什么意义）。Fork/Join在分治的基础上加入了多线程，可以把每个任务分解和合并交给不同的线程来完成，进一步的提高运算效率。示例这是一个计算1-n之间所有整数相加的demo，总体来说所谓的分治思想，类似于递归，将1-n

概述定长线程池的使用过程中会存在饥饿现象，也就是当多线程情况下，当池中所有线程都被占用后，被占用的线程又需要空闲线程去进行下一步的操作，此时又获取不到池中空闲的线程，此时就出现了饥饿现象。示例package com.leolee.multithreadProgramming.threadPool.threadHungry;import lombok.extern.slf4j.Slf4j;import java.util.Arrays;import java.util.List;im

CountDownLatch是JUC下提供的一个计数器，其通过计数递减的方式控制线程的执行顺序。package com.leolee.multithreadProgramming.juc.countDownLatch;import java.util.concurrent.CountDownLatch;/** * @ClassName CountDownLatchTest * @Description: TODO * @Author LeoLee * @Date 2021/3/2 *

使用JUC的原子引用类的CAS特性实现自旋锁直接上代码package com.leolee.multithreadProgramming.test.spinLock;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicReference;/** * @ClassName SpinLockTest * @Description: 自定义自旋锁 * @Author LeoLee *

概述上图是一个线程池的示意图，基本分为线程池和任务等待队列两部分。

概述本文不讨论Atomic原子操作的底层原理与实现，仅针对其缺点进行讨论QaQ。缺点Atomic原子操作类实质上是一个CAS操作的实现，Atomic类的缺点实质上是CAS的缺点：由于Atomic类CAS的实现中，存在do while的循环操作，在最恶劣的情况下，当前线程始终无法对比成功【预期值】，将会进行大量的循环，增加CPU的负荷，以getAndIncrement为例public final int getAndAddInt(Object var1, long var2, int va

不可变定义某些对象是不可以改变的，在没有线程修改其中变量，即使对象是共享的，其也是线程安全的。可变类举例package com.leolee.multithreadProgramming.juc.immutable;import lombok.extern.slf4j.Slf4j;import java.text.ParseException;import java.text.SimpleDateFormat;/** * @ClassName Test * @Descript

Unsafe是一个sun包下的特殊类，包装了很多不便于开发者直接使用的功能方法。本片简单的说明一下Unsafe类中与CAS相关的操作，AtomicXXX等CAS无锁线程安全的工具类底层很多都用到了Unsafe的方法，所以理解和使用Unsafe类CAS相关的方法对AtomicXXX等工具类是非常重要的。Unsafe对象的获取由于Unsafe类无法直接创建（私有的构造方法），采用了单例模式，并且该单例模式的getInstance方法会校验调用该方法的类是否是系统类加载器，看来为了防止开发者直接使用Uns

happens-before规则happens-before规定了对共享变量的写操作对其他线程读操作可见，它是可见性与有序性的一套规则总结，在此规则之外JMM（Java Memory Model, JMM）并不能保证变量的可见性。什么是JMM可参考优快云的一篇文章：JMM概述规则一synchronized保证变量的可见性 int x = 0; static Object lock = new Object(); public void test() {

有序性指令重排说到有序性，总是要提到指令重排：JVM会在不影响正确定的前提下，调整语句的执行顺序。但是指令重排会在多线程下出现线程安全的问题，那么为什么要使用指令重排呢？为了执行的效率。在cpu执行每条指令可以分为如下几个阶段：取指令：instruction fetch（IF） 指令译码：instruction decode（ID） 执行：execute（EX） 内存访问：memory access（MEM） 数据回写：register write back（WB）现代的cpu都支

package com.leolee.multithreadProgramming.concurrent.threadCommunication;import lombok.extern.slf4j.Slf4j;import java.util.concurrent.locks.Condition;import java.util.concurrent.locks.LockSupport;import java.util.concurrent.locks.ReentrantLock;/**.

什么是ReentrantLock简单的来讲ReentrantLock是JUC提供的一种与synchronized关键字加锁作用类似的类。与synchronized关键字相比，ReentrantLock有如下特点：可中断（一个线程可以通过interrupt方法取消另一个线程的锁等待） 可以设置竞争锁资源的超时时间 可以设置公平锁（synchronized关键字释放锁资源之后，其他在关联该对象Monitor的阻塞线程将会再次竞争锁资源，并没有先来先得，后来后得的公平性） 支持多个条件变量（sy

如下代码运行之后会产生死锁：t1线程持有对象锁a在等待对象锁b的释放，t2线程持有对象锁b在等待对象锁a释放package com.leolee.multithreadProgramming.concurrent.syn;import lombok.extern.slf4j.Slf4j;/** * @ClassName DeadLock * @Description: 死锁问题 * @Author LeoLee * @Date 2020/12/7 * @Version V1.0 *

package com.leolee.multithreadProgramming.concurrent.lockSupport;import lombok.extern.slf4j.Slf4j;import java.util.concurrent.locks.LockSupport;/** * @ClassName Test * @Description: LockSupport：JDK线程工具类 * @Author LeoLee * @Date 2020/12/7 * @Ver.

JDK中有很多的阻塞的队列（Queue），这些队列可能是任务队列，可能是消息队列。java线程间的消息队列：指的是消息在多线程之间的生产和消费的。package com.leolee.multithreadProgramming.concurrent.messageQueue;import lombok.extern.slf4j.Slf4j;import java.util.LinkedList;/** * @ClassName Test * @Description: 消息队列模

什么是保护性暂停模式保护性暂停模式就是提供了一种线程间通信能力的模式。如果有一个线程的执行结果需要传递给另一个线程，就需要使用保护性暂停模式将两条线程关联起来。JDK中join方法和Future就是使用了此模式实现的。保护性暂停模式的实现package com.leolee.multithreadProgramming.concurrent.guarded;import lombok.extern.slf4j.Slf4j;/** * @ClassName Test * @D

wait&sleepwait释放锁，sleep不释放 wait是Object的方法，sleep是线程的静态方法 wait需要和synchronized一起使用 wait和sleep之后，线程都处于TIME-WAITING状态 wait的线程处于与当前锁对象相关的waitset中 wait和sleep被Interrupte都会有InterruptedExceptionnotifyobj.notify()随机叫醒一个与obj对象锁相关的waitset中的一个线程 obj.notif

Monitor解释synchronized同步远离之前，首先了解一下Monitor（翻译为监视器，又叫管程，基于操作系统）。首先明确的是每一个Java对象都可以关联一个Monitor对象，当使用synchronized关键字的时候，该对象就会与一个Monitor对象关联，即该对象的Mark word中就会设置一个只想Monitor对象的指针（一个普通的对象包含64 bits的Object head、32 bits的Mark word 以及32 bits的Klass word）。重量级锁加锁原理

成员变量和静态变量是否线程安全很明显如果它们没有被共享，则线程安全 如果它们被共享了，根据他们的状态是否能够改变，又分为如下两种情况 如果只有读操作，线程安全 如果有写操作，使用它们的代码处于临界区，线程不安全​​​​​​​ 局部变量引用线程安全情况示例： //=========================成员变量线程不安全分析============================== static class MemberVariableUnsafe {

什么是两阶段终止模式在一个线程t1中优雅的停止t2线程，优雅指的是给t2一个料理后事的过程，比如释放资源，并不是直接使用stop杀死t2。两阶段终止模式的原理根据以上原理图编写测试代码：package com.leolee.multithreadProgramming.concurrent.thread;import lombok.extern.slf4j.Slf4j;import java.util.concurrent.TimeUnit;/** * @ClassNam

锁重入synchronized拥有锁重入的机制，也就是在使用synchronized时候，当一个线程得到对象锁之后，再次请求此对象锁时是可以再次得到该对象的锁的。简单说就是synchronized修饰的方法或者代码块内部调用本类的其他synchronized方法或者代码块，是永远可以得到锁的。当一条线程获得了对象锁，此时该线程还没有释放该对象锁，当其再次获取这个对象锁的时候还是可以获取的，如果没有这样的设计，就会造成死锁。以上解释摘抄于机械工业出版社《Java多线程编程核心技术》示例很简单，如下

概述我们经常在使用synchronized关键字来修饰方法以保证实例变量的线程安全，今天来讨论一下synchronized关键字的相关特性实现同步synchronized使用起来很简单，比如在方法上使用，在多个线程访问同一个同步方法的时候，由于synchronized获得是对象锁，并不是把每一个方法当作锁，所以哪个线程先执行这个同步方法，哪个线程就持有该方法所属对象的锁，其他线程就需要等待当前持有对象锁的线程释放对象锁。package com.leolee.multithreadProgr