AQS 是抽象的队列同步器，是用来构建锁或其他同步组件的重量级基础框架及整个 JUC 体系的基石。 下边的组件都是基于 AQS 框架扩展实现的： 虽然这些组件在多线程场景下有不同的作用，但代码中也有相似之处，如都需要管理锁状态，维护阻塞线程，维护唤醒线程。而 AQS 的作用就是将这些相似的、公共的代码封装在一起。

LockSupport 是用来创建锁和其他同步类的基本线程阻塞原语，是线程等待唤醒机制的一种实现工具类。 等待唤醒机制 是线程中的一种协作机制。多线程之间不单有竞争锁的情况，还有相互协作的场景。比如线程A执行完某一操作需要挂起一段时间，将运行的机会让给线程B，当线程B执行完任务后就唤醒线程A继续做任务。 Java 提供了 3 种等待唤醒机制：

梳理早期与 Thread 状态相关的笔记。 通过查看 Thread 源码，我们可以看到在其类内部定义了线程的状态枚举： Thread 线程大致分为 6 种，即 NEW，RUNNABLE，BLOCKED， WAITING，TIMED_WAITING，TERMINATED。

CAS 全程 Compare-And-Swap，它的功能是判断内存中某个位置的值是否为预期值，如果是则更改为新值，这个过程是原子性的。 CAS 是另一个无锁解决方案，更准确的是采用乐观锁技术，实现线程安全的问题。 在设计思想上，CAS 的执行有三个操作数，V-内存值，A-期望值，B-修改成的目标值。当且仅当 V 的值等于 A 时， CAS 通过原子方式用新值 B 来更新 V 的值，否则不会执行任何操作。

在大型系统的分布式系统中，系统会被拆分成了许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。 在这种架构中，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心，也就意味着这种架构形式也会存在一些问题： 针对上边的问题，网上大牛已给出解决思路：分布式链路追踪（Distributed Tracing）。

Spring Cloud 原先整合 Zuul 作为网关组件，Zuul 由 Netflix 公司提供的，现在已经不维护了。后面 Netflix 公司又出来了一个 Zuul2.0 网关，但由于一直没有发布稳定版本，所以 Spring Cloud 等不及了就自己推出一个网关，已经不打算整合 zuul2.0 了。 Spring Cloud Gateway 是 Spring 公司基于 Spring 5.0， Spring Boot 2.0 和 Project Reactor 等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。它的目标是替代 Netflix Zuul，其不

在微服务架构中，我们将业务拆分成一个个的服务，服务与服务之间可以相互调用，但是由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟，此时若有大量的网络涌入，会形成任务堆积，最终导致服务瘫痪。 由于服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩效应”，如下图：

之前写过一篇 《Mybatis 插件实现动态设置参数》 文章，介绍了 Mybatis 插件的扩展和使用。笔者在空闲时间梳理了一下 MyBatis 插件的工作原理，在此记录和分享其插件功能代码的演化过程。 我们简略 MyBatis 执行 SQL 的步骤，下边的原始代码是依靠 Executor 执行 SQL 语句。 假设，我们需要 Executor 在执行 SQL 语句的前后打印出当前时间戳（方法增强），那该如何操作？

在工作中时常会使用 Java Stream 对集合进行特殊操作，Stream 虽然能简化代码，但是书写以及阅读性不高。故在此记录常用的 Stream 案例以便在未来工作中查阅和使用（复制粘贴😅） Stream 是 Java8 中处理集合的关键抽象概念，它可以指定你希望对集合进行的操作，可以执行非常复杂的查找、过滤和映射数据等操作。 使用Stream API 对集合数据进行操作，就类似于使用 SQL 执行的数据库查询。也可以使用 Stream API 来并行执行操作。简而言之，Stream API 提供了一种高效且易于使用的处理数据的方式。