Java 搬运工 & 终身学习者

前言

在微服务架构中，服务间的依赖关系复杂且动态，任何一个服务的故障都可能引发连锁反应，导致系统雪崩。一个好的容错设计可以避免这些问题发生：

• 服务雪崩效应：单个服务崩溃或响应延迟可能导致调用链上的所有服务被阻塞，最终拖垮整个系统。例如，若服务 A 依赖服务 B，而服务 B 因高负载无法响应，A 的线程池可能被占满，进而影响其他依赖A的服务；

• 分布式系统的脆弱性：网络抖动、节点宕机、资源耗尽等问题在分布式环境中不可避免。容错机制通过冗余和快速失败策略，确保部分故障不会扩散到整个系统；

• 服务的可用性低：微服务的目标是提升系统可用性，而容错设计（如故障转移、熔断）是保障服务持续可用的核心手段。例如，通过自动切换健康节点，避免单点故障。

前言

论文（Paper）通常是新技术、算法、编程方法或软件工具的首次公布。通过阅读论文，我们可以了解最新的技术进展，保持自己的技能和知识是最新的。
同时，论文提供了对特定主题深入理解的机会。它们通常包含详细的理论分析和实验结果，这有助于深入理解某个概念或技术。但是，如何高效地阅读论文是一项关键但很少有人谈论的技能。刚开始大部分人自己通过试错来学习，但常常被挫败感所劝退。本文介绍一种阅读论文的方法——三遍阅读法。

《UNIX 传奇：历史与回忆》 是 bwk（Brian W. Kernighan）2019 年的新作，回忆了 UNIX 在大半个世纪的风雨历程，是一本引人入胜的书籍。通过对 UNIX 操作系统的历史和发展进行详细的叙述和回顾，让我对这个操作系统有了更深入的了解。读完这本书，我不仅对 UNIX 的技术细节有了更清晰的认识，也对 UNIX 的影响力和价值有了更深刻的体会。

前言

Goroutines 是 Go 语言主要的并发原语。它看起来非常像线程，但是相比于线程它的创建和管理成本很低。Go 在运行时将 goroutine 有效地调度到真实的线程上，以避免浪费资源，因此您可以轻松地创建大量的 goroutine（例如每个请求一个 goroutine），并且您可以编写简单的，命令式的阻塞代码。因此，Go 的网络代码往往比其它语言中的等效代码更直接，更容易理解（这点从下文中的示例代码可以看出）。

对我来说，goroutine 是将 Go 这门语言与其它语言区分开来的一个主要特征。这就是为什么大家更喜欢用 Go 来编写需要并发的代码。在下面讨论更多关于 goroutine 之前，我们先了解一些历史，这样你就能理解为什么你想要它们了。

前言

大部分人在日常的业务开发中，其实很少去关注数据库的事务相关问题，基本上都是 CURD 一把梭。正好最近在看 MySQL 的相关基础知识，其中对于幻读问题之前一直没有理解深刻，今天就来聊聊「InnoDB 是如何解决幻读的」，话不多说，下面进入主题。

前言

首先需要明确的是 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 在不影响性能的情况下，同时解决了这两种方式存在的缺点。