死磕 Java

DCL，即Double Check Lock，中卫双重检查锁定。其实DCL很多人在单例模式中用过，LZ面试人的时候也要他们写过，但是有很多人都会写错。他们为什么会写错呢？其错误根源在哪里？有什么解决方

「这是我参与11月更文挑战的第 4 天，活动详情查看：2021最后一次更文挑战 记得刚刚开始学习Java的时候，一遇到多线程情况就是synchronized，相对于当时的我们来说synchronize

「这是我参与11月更文挑战的第 9 天，活动详情查看：2021最后一次更文挑战 前篇博客【死磕Java并发】-----深入分析volatile的实现原理 中已经阐述了volatile的特性了： vol

通过前面一章我们了解了synchronized是一个重量级的锁，虽然JVM对它做了很多优化，而下面介绍的volatile则是轻量级的synchronized。如果一个变量使用volatile，则它比使

「这是我参与11月更文挑战的第 7 天，活动详情查看：2021最后一次更文挑战 在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，但是不能随意重排序，不是你想怎么排序就怎么排序，它需要

「这是我参与11月更文挑战的第 6 天，活动详情查看：[2021最后一次更文挑战](https://juejin.cn/post/7023643374569816095/ "https://jueji

「这是我参与11月更文挑战的第 12 天，活动详情查看：2021最后一次更文挑战 Java的内置锁一直都是备受争议的，在JDK 1.6之前，synchronized这个重量级锁其性能一直都是较为低下，

「这是我参与11月更文挑战的第 11 天，活动详情查看：2021最后一次更文挑战 经过四篇博客阐述，我相信各位对Java内存模型有了最基本认识了，下面LZ就做一个比较简单的总结。 总结 JMM规定了线

「这是我参与11月更文挑战的第 15 天，活动详情查看：2021最后一次更文挑战 -- 在线程获取同步状态时如果获取失败，则加入CLH同步队列，通过通过自旋的方式不断获取同步状态，但是在自旋的过程中则

「这是我参与11月更文挑战的第 15 天，活动详情查看：2021最后一次更文挑战 ReentrantLock，可重入锁，是一种递归无阻塞的同步机制。它可以等同于synchronized的使用，但是Re

前面三篇博客分别介绍了CyclicBarrier、CountDownLatch、Semaphore，现在介绍并发工具类中的最后一个Exchange。Exchange是最简单的也是最复杂的，简单在于AP

「这是我参与11月更文挑战的第 13 天，活动详情查看：2021最后一次更文挑战 在上篇博客【死磕Java并发】-----J.U.C之AQS：AQS简介中提到了AQS内部维护着一个FIFO队列，该队列

「这是我参与11月更文挑战的第 14 天，活动详情查看：2021最后一次更文挑战 在前面提到过，AQS是构建Java同步组件的基础，我们期待它能够成为实现大部分同步需求的基础。AQS的设计模式采用的模

「这是我参与11月更文挑战的第 19 天，活动详情查看：2021最后一次更文挑战 CAS，Compare And Swap，即比较并交换。Doug lea大神在同步组件中大量使用CAS技术鬼斧神工地实

CyclicBarrier，一个同步辅助类，在API中是这么介绍的： 它允许一组线程互相等待，直到到达某个公共屏障点 (common barrier point)。在涉及一组固定大小的线程的程序中，这

在上篇博客中介绍了Java四大并发工具一直的CyclicBarrier，今天要介绍的CountDownLatch与CyclicBarrier有点儿相似。 CyclicBarrier所描述的是“允许一组

HashMap是我们用得非常频繁的一个集合，但是由于它是非线程安全的，在多线程环境下，put操作是有可能产生死循环的，导致CPU利用率接近100%。为了解决该问题，提供了Hashtable和Colle

在【死磕Java并发】-----J.U.C之Java并发容器：ConcurrentHashMap一文中详细阐述了ConcurrentHashMap的实现过程，其中有提到在put操作时，如果发现链表结构

信号量Semaphore是一个控制访问多个共享资源的计数器，和CountDownLatch一样，其本质上是一个“共享锁”。 Semaphore，在API是这么介绍的： 一个计数信号量。从概念上讲，信号

持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第 2 天，点击查看活动详情 要实现一个线程安全的队列有两种方式：阻塞和非阻塞。阻塞队列无非就是锁的应用，而非阻塞则是CAS算法的应