前言

高效并发是从 JDK 1.5 到 JDK 1.6 的一个重要改进，HotSpot 虚拟机开发团队在这个版本上花费了大量的精力去实现各种锁优化技术，如适应性自旋（Adaptive Spinning）、锁消除（Lock Elimination）、锁粗化（Lock Coarsening）、轻量级锁（Lightweight Locking）和偏向锁（Biased Locking）等，这些技术都是为了在线程之间高效地共享数据，以及解决竞争问题，从而提交程序的执行效率。

上一篇文章中，我们针对 Java 并发编程进行了了解，如线程以及线程安全概念、Java 内存模型等基础性知识。本章，我们针对 Java 提供的种类丰富的锁，为读者介绍主流锁的知识点，以及不同的锁的适用场景。

背景

在本系列的前一篇博文中，笔者对消息队列的概述、特点等进行讲解，然后对消息队列使用场景进行分析，最后对市面上比较常见的消息队列产品进行技术对比。

经过上一篇博客介绍，相信大家对消息队列已经有了一个大致了解。RabbitMQ 是 MQ 产品的典型代表，是一款基于 AMQP 协议可复用的企业消息系统。业务上，可以实现服务提供者和消费者之间的数据解耦，提供高可用性的消息传输机制，在实际生产中应用相当广泛。本文意在介绍 RabbitMQ 的基本原理，包括 RabbitMQ 基本框架、概念、通信过程等，介绍一下 RabbitMQ 安装教程，最后介绍一下 RabbitMQ 在项目中实际应用场景。

前言

JDK 5 引入了 Future 模式。Future 接口是 Java 多线程 Future 模式的实现，在 java.util.concurrent 包中，可以来进行异步计算。虽然 Future 以及相关使用方法提供了异步执行任务的能力，但是对于结果的获取却是很不方便，只能通过阻塞或者轮询的方式得到任务的结果。阻塞的方式显然和我们的异步编程的初衷相违背，轮询的方式又会耗费无谓的 CPU 资源，而且也不能及时地得到计算结果，为什么不能用观察者设计模式当计算结果完成及时通知监听者呢？如 Netty、Guava 分别扩展了 Java 的 Future 接口，方便异步编程。

为了解决这个问题，自 JDK8 开始，吸收了 Guava 的设计思想，加入了 Future 的诸多扩展功能形成了 CompletableFuture，让 Java 拥有了完整的非阻塞编程模型。CompletableFuture 它提供了非常强大的 Future 的扩展功能，可以帮助我们简化异步编程的复杂性，并且提供了函数式编程的能力。CompletableFuture 能够将回调放到与任务不同的线程中执行，也能将回调作为继续执行的同步函数，在与任务相同的线程中执行。它避免了传统回调最大的问题，那就是能够将控制流分离到不同的事件处理器中。

CompletableFuture 弥补了 Future 模式的缺点。在异步的任务完成后，需要用其结果继续操作时，无需等待。可以直接通过 thenAccept、thenApply、thenCompose 等方式将前面异步处理的结果交给另外一个异步事件处理线程来处理。

背景

在本系列的前一篇博文中，笔者对 RabbitMQ 基本框架、概念、通信过程等基础原理，RabbitMQ 安装教程，RabbitMQ 在项目中实际应用场景等进行了详细的讲解。经过上一篇博客介绍，相信大家对 RabbitMQ 已经有了一个大致了解。Kafka 是由 LinkedIn 公司采用 Scala 语言开发的一个分布式、多分区、多副本且基于 Zookeeper 协调的分布式消息系统，现已捐献给 Apache 基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如 Cloudera、Apache Storm、Spark、Flink 等都支持与 Kafka 集成。

本文意在介绍 Kafka 的基本原理，包括 Kafka 基本概念、通信过程等，介绍一下 Kafka 安装教程，最后介绍一下 Kafka 在项目中实际应用场景。

背景

Java 11 已于 2018 年 9 月 25 日正式发布，Java 开发团队为了加快的版本迭代、跟进社区反馈，Java 的版本发布周期调整为每六个月一次——即每半年发布一个大版本，每个季度发布一个中间特性版本，并且做出不会跳票的承诺。通过这样的方式，Java 开发团队能够将一些重要特性尽早的合并到 Java Release 版本中，以便快速得到开发者的反馈，避免出现类似 Java 9 发布时的两次延期的情况。

本文主要针对 Java 9 - Java 11 中的新特性展开介绍，让您快速了解 Java 9 - Java 11 带来的变化。

前言

现在是 2020 年 1 月 22 日，戊戌狗年，腊月十七，星期三，也是今年我在公司上班的最后一天。临近年末，各个项目已经陆续的开始封版，我也开始光明正大的摸鱼了，终于体会到 “摸鱼一时爽，一直摸鱼一只爽”。哈哈哈哈哈，开玩笑。按道理来说，本来 2019 年度总结，我应该在 2019 年 12 月 31 日写完，然后在 2020 年 1 月 1 日发表出来，这样的节奏，生活才有仪式感。那么为什么不是这样的节奏进行呢？因为我的拖延症又又又犯了，我可太难了 (┬＿┬)。在 2019 年年末没有完成年终总结，本来打算就不写了。后来想想还是打算写一下，一方面是因为之前从来没有写过年终总结，另一方面是今年我的生活还是发生了很大的变化，是值得纪念的一年，因此还是想把我的 2019 年总结一下。那么，我就开始回顾一下我的 2019 年。

前言

在许多情况下，让计算机同时去做几件事情，不仅是因为计算机的运算能力强大了，还有一个重要的原因是计算机的运算速度与它的存储和通信子系统速度的差距太大，大量的时间都花费在磁盘 I/O、网络通信和数据库访问上。因此，让计算机同时处理几项任务是充分利用计算机处理器的能力最有效的手段。

服务端是 Java 语言最擅长的领域之一，而线程是 Java 语言中不可或缺的重要功能，它们能使复杂的异步代码变得更加简单，从而极大地简化了复杂系统的开发。此外，要想充分发挥多处理器的强大计算能力，最简单的方式就是使用线程。随着处理器数量的持续增长，如何高效地使用并发正变得越来越重要。

本章作为 Java 并发编程的开篇，首先大致介绍了一下线程以及线程安全的概念，然后详细介绍了一下 Java 内存模型，最后针对常见的 Java 并发编程进行问与答。

前言

处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及 Full GC 次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。给一个系统定位问题的时候，知识、经验是关键基础，数据是依据，工具是运用处理数据的手段。这里说的数据包括：运行日志、异常堆栈、GC 日志、线程快照（threaddump/javacore 文件）、堆转侟快照（heapdump/hprof 文件）等。经常使用适当的虚拟机监控和分析的工具可以加快我们分析数据、定位解决问题的速度。

对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出 jstack 和内存信息，然后重启系统，尽快保证系统的可用性。本文主要针对 JDK 的命令行工具，主要包括用于监视虚拟机和故障处理的工具。根据 JDK 的命令行工具提供解决问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。

前言

在本系列的前两篇博文中，笔者对 Git 以及 Git flow 进行了大致的介绍，相信各位读者已经对 Git 有了大致的了解。但是，在我们的日常工作中使用 Git 时常会遇到的各种突发状况，那么我们应该怎么合理的应对这些状况呢？俗话说，无规矩不成方圆，在团队协作中，如何规范 Git Commit 呢？本文将针对以上问题展开讨论，探讨一下在日常工作中，我们应该如何优雅的使用 Git？

前言

在微服务架构中，随着服务的逐步拆分，数据库私有已经成为共识，这也导致所面临的分布式事务问题成为微服务落地过程中一个非常难以逾越的障碍，但是目前尚没有一个完整通用的解决方案。

其实不仅仅是在微服务架构中，随着用户访问量的逐渐上涨，数据库甚至是服务的分片、分区、水平拆分、垂直拆分已经逐渐成为较为常用的提升瓶颈的解决方案，因此越来越多的原子操作变成了跨库甚至是跨服务的事务操作。最终结果是在对高性能、高扩展性、高可用性的追求的道路上，我们开始逐渐放松对一致性的追求，但是在很多场景下，尤其是账务，电商等业务中，不可避免的存在着一致性问题，使得我们不得不去探寻一种机制，用以在分布式环境中保证事务的一致性。

分布式事务有多种主流形态，包括：

• 基于 2PC（两阶段提交）实现的分布式事务
• 基于 3PC（三阶段提交）实现的分布式事务
• 基于 TCC（补偿事务）实现的分布式事务
• 基于 Saga 实现的分布式事务
• 基于可靠消息（事务消息）最终一致性实现的分布式事务
• 基于本地消息（本地消息表）最终一致性实现的分布式事务

接下来，本文将对这些形态的分布式事务进行剖析，然后讲解一下如何根据业务选择对应的分布式事务形态。