Java 搬运工 & 终身学习者。

前言

首先需要明确的是 TCP 是一个可靠传输协议，它的所有特点最终都是为了这个可靠传输服务。在网上看到过很多文章讲 TCP 连接的三次握手和断开连接的四次挥手，但是都太过于理论，看完感觉总是似懂非懂。反复思考过后，觉得我自己还是偏工程型的人，要学习这些理论性的知识，最好的方式还是要通过实际案例来理解，这样才会具象深刻。本文通过 Wireshark 抓包来分析 TCP 三次握手和四次挥手，如果你也对这些理论感觉似懂非懂，那么强烈建议你也结合抓包实践来强化理解这些理论性的知识。

前言

在 Spring 框架中有很多实用的功能，不需要写大量的配置代码，只需添加几个注解即可开启。 其中一个重要原因是那些 @EnableXXX 注解，它可以让你通过在配置类加上简单的注解来快速地开启诸如事务管理（@EnableTransactionManagement）、Spring MVC（@EnableWebMvc）或定时任务（@EnableScheduling）等功能。这些看起来简单的注解语句提供了很多功能，但它们的内部机制从表面上看却不太明显。 一方面，对于使用者来说用这么少的代码获得这么多实用的功能是很好的，但另一方面，如果你不了解某个东西的内部是如何工作的，就会使调试和解决问题更加困难。

一维码（条形码）

在介绍二维码之前，先来看看它的“大哥”一维码，一维码也叫条形码（好像在日常生活中都是叫这个），它是由不同宽度的黑条和白条按照一定的顺序排列组成的平行线图案，它的宽度记录着数据信息，长度没有记录信息，条形码常用于标出物品的生产国、制造厂家、商品名称、生产日期、图书分类号、邮件起止地点、类别、日期等信息，比如大部分食品包装袋背后都会印有条形码。

前言

在并发编程中，当多个线程同时访问同一个共享的可变变量时，会产生不确定的结果，所以要编写线程安全的代码，其本质上是对这些可变的共享变量的访问操作进行管理。导致这种不确定结果的原因就是可见性、有序性和原子性问题，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.