Java 搬运工 & 终身学习者。

前言

在并发编程中，当多个线程同时访问同一个共享的可变变量时，会产生不确定的结果，所以要编写线程安全的代码，其本质上是对这些可变的共享变量的访问操作进行管理。导致这种不确定结果的原因就是可见性、有序性和原子性问题，Java 为解决可见性和有序性问题引入了 Java 内存模型，使用互斥方案（其核心实现技术是锁）来解决原子性问题。这篇先来看看解决可见性、有序性问题的 Java 内存模型（JMM）。

前言

在我们日常开发的分层结构的应用程序中，为了各层之间互相解耦，一般都会定义不同的对象用来在不同层之间传递数据，因此，就有了各种 XXXDTO、XXXVO、XXXBO 等基于数据库对象派生出来的对象，当在不同层之间传输数据时，不可避免地经常需要将这些对象进行相互转换。

此时一般处理两种处理方式：① 直接使用 Setter 和 Getter 方法转换、② 使用一些工具类进行转换（e.g. BeanUtil.copyProperties）。第一种方式如果对象属性比较多时，需要写很多的 Getter/Setter 代码。第二种方式看起来虽然比第一种方式要简单很多，但是因为其使用了反射，性能不太好，而且在使用中也有很多陷阱。而今天要介绍的主角 MapStruct 在不影响性能的情况下，同时解决了这两种方式存在的缺点。

前言

异步编程是让程序并发运行的一种手段。它允许多个事情同时发生，当程序调用需要长时间运行的方法时，它不会阻塞当前的执行流程，程序可以继续运行，当方法执行完成时通知给主线程根据需要获取其执行结果或者失败异常的原因。使用异步编程可以大大提高我们程序的吞吐量，可以更好的面对更高的并发场景并更好的利用现有的系统资源，同时也会一定程度上减少用户的等待时间等。本文我们一起来看看在 Java 语言中使用异步编程有哪些方式。

什么是 Fork/Join 框架

Fork/Join 框架是一种在 JDK 7 引入的线程池，用于并行执行把一个大任务拆成多个小任务并行执行，最终汇总每个小任务结果得到大任务结果的特殊任务。通过其命名也很容易看出框架主要分为 Fork 和 Join 两个阶段，第一阶段 Fork 是把一个大任务拆分为多个子任务并行的执行，第二阶段 Join 是合并这些子任务的所有执行结果，最后得到大任务的结果。

这里不难发现其执行主要流程：首先判断一个任务是否足够小，如果任务足够小，则直接计算，否则，就拆分成几个更小的小任务分别计算，这个过程可以反复的拆分成一系列小任务。Fork/Join 框架是一种基于 分治 的算法，通过拆分大任务成多个独立的小任务，然后并行执行这些小任务，最后合并小任务的结果得到大任务的最终结果，通过并行计算以提高效率。

什么是循环依赖

什么是循环依赖呢？可以把它拆分成循环和依赖两个部分来看，循环是指计算机领域中的循环，执行流程形成闭合回路；依赖就是完成这个动作的前提准备条件，和我们平常说的依赖大体上含义一致。放到 Spring 中来看就一个或多个 Bean 实例之间存在直接或间接的依赖关系，构成循环调用，循环依赖可以分为直接循环依赖和间接循环依赖，直接循环依赖的简单依赖场景：Bean A 依赖于 Bean B，然后 Bean B 又反过来依赖于 Bean A（Bean A -> Bean B -> Bean A），间接循环依赖的一个依赖场景：Bean A 依赖于 Bean B，Bean B 依赖于 Bean C，Bean C 依赖于 Bean A，中间多了一层，但是最终还是形成循环（Bean A -> Bean B -> Bean C -> Bean A）。

前言

在 上篇 介绍了 Feign 的核心实现原理，在文末也提到了会再介绍其和 Spring Cloud 的整合原理，Spring 具有很强的扩展性，会把一些常用的解决方案通过 starter 的方式开放给开发者使用，在引入官方提供的 starter 后通常只需要添加一些注解即可使用相关功能（通常是 @EnableXXX）。下面就一起来看看 Spring Cloud 到底是如何整合 Feign 的。

What is Feign

Feign 是⼀个 HTTP 请求的轻量级客户端框架。通过 接口 + 注解的方式发起 HTTP 请求调用，面向接口编程，而不是像 Java 中通过封装 HTTP 请求报文的方式直接调用。服务消费方拿到服务提供方的接⼝，然后像调⽤本地接⼝⽅法⼀样去调⽤，实际发出的是远程的请求。让我们更加便捷和优雅的去调⽤基于 HTTP 的 API，被⼴泛应⽤在 Spring Cloud 的解决⽅案中。开源项目地址：Feign，官方描述如下：

Feign is a Java to HTTP client binder inspired by Retrofit, JAXRS-2.0, and WebSocket. Feign’s first goal was reducing the complexity of binding Denominator uniformly to HTTP APIs regardless of ReSTfulness.

前言

我们现在所处的信息爆炸时代，如何强调快速获取信息都不为过，信息多种多样，有些能找到源头，有些则不能，有些能找到规律，有些则不一定能找到，信息的源头和获取渠道很重要。然而事实上，能够真正有效获取到优质信息并加以消化利用的人并不多。

在信息的获取的过程中，应该要具备筛选信息的能力，什么是官方信息，你要核实，什么是虚假信息，你要甄别。看到网上有些陷入杀猪盘的，负载累累。仔细思考一下，其实甄别筛选信息的能力真的是最大的问题。

当然一个人将信息并内化利用是一个很复杂的过程，每个人都有自己独到的方法。今天来聊聊应该如何去获取「优质信息」以及如何去过滤无用信息。下面分享几个获取信息的原则：

前言

在 上篇 实现了 判断一个类的方式是符合配置的 pointcut 表达式、根据一个 Bean 的名称和方法名，获取 Method 对象、实现了 BeforeAdvice、AfterReturningAdvice 以及 AfterThrowingAdvice并按照指定次序调用 等功能，这篇再来看看剩下的 代理对象如何生成、根据 XML 配置文件生成 BeanDefintion以及如何将生成的代理对象放入到容器中 等功能，话不多说，下面进入主题。

前言

前面两篇 如何实现 AOP（上）、如何实现 AOP（中） 做了一些 AOP 的核心基础知识简要介绍，本文进入到了实战环节了，去实现一个基于 XML 配置的简易版 AOP，虽然是简易版的但是麻雀虽小五脏俱全，一些核心的功能都会实现，通过实现这个简易版的 AOP，相信你会对 AOP 会有更加深入的理解，不止知其然，还能知其所以然。AOP 的顶层接口规范和底层依赖基础组件都是由一个叫 AOP Alliance 的组织制定的，我们经常听到的 AspectJ、ASM、CGLIB 就是其中被管理的一些项目，需要明确的一点是，在 Spring 中只是使用了 AspectJ 的核心概念和核心类，并不是像 AspectJ 那样在编译期实现的 AOP，而是在运行期。话不多说，下面开始进入主题。