局部变量保证线程安全

AQS源码详细解读

[TOC]

基础

在讲解AQS之前，有几个额外的知识需要了解。知道了这些，才能明白AQS框架中很多代码的道理。

• CAS相关知识
• 通过标识位进行线程挂起的并发编程范式
• MPSC队列的实现技巧

欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

理解 Java 内存模型的因果性约束

[TOC]

欢迎讨论

欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

规范理解

这部分的内容比较抽象，首先是一开始的定义，如下

高性能Java序列化框架Fse发布

[TOC]

使用场景

将Java对象序列化为二进制数据进行保存，以及二进制数据反向序列化为Java对象，在很多场景中都有应用。比如将对象序列化后离线存储至其他介质，或者存储于Redis这样的缓存之中。

目前常见的有几种框架可以支撑，比如 Hession ，Kryo，Fst，Protobuf，JDK原生等。有一些框架需要提前编写元数据配置文件以支撑跨语言序列化能力，比如 Protobuf 。不过如果团队的技术栈是统一的 Java 体系的话，则能够开箱即用的序列化框架使用起来会更加方便一些，特别有些时候对象特别复杂，编写元数据配置文件也是很繁琐的一个事情。

Fse 框架正是应用于这样的场景，不需要编写元数据配置信息，开箱即用的 Java 序列化框架，对需要序列化的对象没有任何特殊要求。在性能基准测试中，该框架的性能表现显著优于其他框架，下面是测试对比

欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

心跳与超时：高并发高性能的时间轮超时器

[TOC]

引言

在许多业务场景中，我们都会碰到延迟任务，定时任务这种需求。特别的，在网络连接的场景中，常常会出现一些超时控制。由于服务端的连接数量很大，这些超时任务的数量往往也是很庞大的。实现对大量任务的超时管理并不是一个容易的事情。

本章我们将介绍几种用于实现超时任务的数据结构，并且最后分析 Netty 在超时任务上采取的结构和代码。

欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

支持优先级内部晋升的无锁并发优先级线程池

[TOC]

引言

在技术群讨论到一个有意思的业务需求，可以描述为：

有一个内部按照优先级进行任务排序的线程池。线程池会优先执行高优先级的任务。随着时间的流逝，线程池内部低优先级的任务的优先级会逐渐晋升变为高优先级，以避免被不断新增的高优先级任务阻塞导致饿死。

考虑到 JDK 已经为开发者提供了自定义线程池ThreadPoolExecutor以及优先级队列PriorityBlockingQueue，两者相结合并且定期调整队列中低优先级任务的优先级再进行resort将低优先级的任务调整到队列的前头，也可以一定程度上避免被饿死。

这种方案的问题在于resort的消耗比较高，并且还需要重新计算每一个任务的优先级。为此，引出我们下面的设计，希望使用无锁并发的数据结构存储任务，并且任务支持自动的优先级晋升，保证低优先级的任务最终能够执行而不会被不断增加的高优先级任务饿死。

欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

最终一致性：BASE论文笔记

[TOC]

简述

Base论文是ebay的架构师于2008年提交的一篇论文。主要用来阐述在分布式架构设计下，基于BASE的设计思想和方案。所谓BASE就是basically available（基本的可用性），soft state（软状态，所谓的软状态，指的是暂时的不一致，后文会详细展开），eventually consistent（最终一致性）。在分布式领域，有著名的CAP理论，也就是一致性，可用性，分区容错性即可靠性,这三者无法同时获得。而base理论就是在牺牲部分一致性的基础上，来达到可用性的大幅提升的一种方案理念。
欢迎加入技术交流群186233599讨论交流，也欢迎关注笔者公众号：风火说。

Activiti架构分析及源码详解

[TOC]

引言

工作流引擎，应用于解决流程审批和流程编排方面等问题，有效的提供了扩展性的支撑。而目前来说，工作流领域也有了相对通行化的标准规范，也就是BPMN2.0。支持这个规范的开源引擎主要有：Activiti，flowable，Jbpm4等。本文着重对Activiti的架构设计进行分析和梳理，同时对流程启动和原子操作的相关代码进行完整走读。

本文的阅读对象需要对Activiti有一定的理解并且已经能够初步的使用Activiti进行流程流转方面开发。

欢迎加入技术交流群186233599讨论交流，也欢迎关注技术公众号：风火说。

从2-3-4树模型到红黑树实现

[TOC]

前言

红黑树，是一个高效的二叉查找树。其定义特性保证了树的路径长度在黑色节点上完美平衡，使得其查找效率接近于完美平衡的二叉树。

但是红黑树的实现逻辑很复杂，各种旋转，颜色变化，直接针对其分析，大多数都是死记硬背各种例子，不太容易有个直观的理解。实际上，红黑树是实现手段，是其他概念模型为了方便在二叉树上实现进而定义的节点颜色这个信息。如果从概念模型入手，再一一对应，就容易理解的多了。而红黑树能够对应的模型有2-3树，2-3-4树等，下面我们会以2-3-4树作为概念模型，对红黑树进行分析。

欢迎加入技术交流群186233599讨论交流，也欢迎关注技术公众号：风火说。

ConcurrentHashMap源码走读

[TOC]

简介

在从JDK8开始，为了提高并发度，ConcurrentHashMap的源码进行了很大的调整。在JDK7中，采用的是分段锁的思路。简单的说，就是ConcurrentHashMap是由多个HashMap构成。当需要进行写入操作的时候，会寻找到对应的HashMap，使用synchronized对对应的hashmap加锁，然后执行写入操作。显然，并发程度就取决于HashMap个数的多少。而在JDK8中换了一种完全不同的思路。

首先，仍然是使用Entry[]作为数据的基本存储。但是锁的粒度被缩小到了数组中的每一个槽位上，数据读取的可见性依靠volatile来保证。而在尝试写入的时候，会将对应的槽位上的元素作为加锁对象，使用synchronized进行加锁，来保证并发写入的安全性。

除此之外，如果多个Key的hashcode在取模后落在了相同的槽位上，在一定数量内（默认是8），采用链表的方式连接节点；超过之后，为了提高查询效率，会将槽位上的节点转为使用红黑树结构进行存储。

还有一个比较大的改变在于当进行扩容的时候，除了扩容线程本身，如果其他线程识别到了扩容进行中，则会尝试协助扩容。

下面来看下来针对几个重点方法进行源码分析。

欢迎加入技术交流群186233599讨论交流，也欢迎关注技术公众号：风火说。