Spring Framework 综述

Spring Framework 简介

Spring Framework 是最受欢迎的企业级 Java 应用程序开发框架。用于构建企业级应用的轻量级、一站式解决方案。

当谈论到大小和透明度时， Spring 是轻量级的。 Spring 框架的基础版本是在 2 MB 左右的。

Spring 框架的核心特性可以用于开发任何 Java 应用程序，但是在 Java EE 平台上构建 web 应用程序是需要扩展的。 Spring 框架的目标是使 J2EE 开发变得更容易使用，通过启用基于 POJO 编程模型来促进良好的编程实践。

Spring Framework 设计理念如下：

• 力争让选择无处不在
• 体现海纳百川的精神
• 保持后向兼容性
• 专注 API 设计
• 追求严苛的代码质量

为什么使用 Spring

下面列出的是使用 Spring 框架主要的好处：

• Spring 可以使开发人员使用 POJOs 开发企业级的应用程序。只使用 POJOs 的好处是你不需要一个 EJB 容器产品，比如一个应用程序服务器，但是你可以选择使用一个健壮的 servlet 容器，比如 Tomcat 或者一些商业产品。
• Spring 在一个单元模式中是有组织的。即使包和类的数量非常大，你只需要选择你需要的部分，而忽略剩余的那部分。
• Spring 不会让你白费力气做重复工作，它真正的利用了一些现有的技术，像几个 ORM 框架、日志框架、JEE、Quartz 和 JDK 计时器，其他视图技术。
• 测试一个用 Spring 编写的应用程序很容易，因为 environment-dependent 代码被放进了这个框架中。此外，通过使用 JavaBean-style POJOs，它在使用依赖注入注入测试数据时变得更容易。
• Spring 的 web 框架是一个设计良好的 web MVC 框架，它为 web 框架，比如 Structs 或者其他工程上的或者很少受欢迎的 web 框架，提供了一个很好的供替代的选择。
• 为将特定技术的异常（例如，由 JDBC、Hibernate，或者 JDO 抛出的异常）翻译成一致的， Spring 提供了一个方便的 API，而这些都是未经检验的异常。
• 轻量级的 IOC 容器往往是轻量级的，例如，特别是当与 EJB 容器相比的时候。这有利于在内存和 CPU 资源有限的计算机上开发和部署应用程序。
• Spring 提供了一个一致的事务管理界面，该界面可以缩小成一个本地事务（例如，使用一个单一的数据库）和扩展成一个全局事务（例如，使用 JTA）。

核心思想

Spring 最核心的两个技术思想是：IoC 和 Aop

IoC

IoC 即 Inversion of Control ，意为控制反转。

Spring 最认同的技术是控制反转的依赖注入（DI）模式。控制反转（IoC）是一个通用的概念，它可以用许多不同的方式去表达，依赖注入仅仅是控制反转的一个具体的例子。

当编写一个复杂的 Java 应用程序时，应用程序类应该尽可能的独立于其他的 Java 类来增加这些类可重用可能性，当进行单元测试时，可以使它们独立于其他类进行测试。依赖注入（或者有时被称为配线）有助于将这些类粘合在一起，并且在同一时间让它们保持独立。

到底什么是依赖注入？让我们将这两个词分开来看一看。这里将依赖关系部分转化为两个类之间的关联。例如，类 A 依赖于类 B。现在，让我们看一看第二部分，注入。所有这一切都意味着类 B 将通过 IoC 被注入到类 A 中。

依赖注入可以以向构造函数传递参数的方式发生，或者通过使用 setter 方法 post-construction。由于依赖注入是 Spring 框架的核心部分，所以我将在一个单独的章节中利用很好的例子去解释这一概念。

Aop

Spring 框架的一个关键组件是面向方面的程序设计（AOP）框架。一个程序中跨越多个点的功能被称为横切关注点，这些横切关注点在概念上独立于应用程序的业务逻辑。有各种各样常见的很好的关于方面的例子，比如日志记录、声明性事务、安全性，和缓存等等。

在 OOP 中模块化的关键单元是类，而在 AOP 中模块化的关键单元是方面。AOP 帮助你将横切关注点从它们所影响的对象中分离出来，然而依赖注入帮助你将你的应用程序对象从彼此中分离出来。

Spring 框架的 AOP 模块提供了面向方面的程序设计实现，允许你定义拦截器方法和切入点，可以实现将应该被分开的代码干净的分开功能。我将在一个独立的章节中讨论更多关于 Spring AOP 的概念。

Spring 体系结构

Spring 当前框架有20个 jar 包，大致可以分为6大模块:

• 1. 为什么使用 Spring
• 2. 核心思想
  • 2.1. IoC
  • 2.2. Aop
• 3. Spring 体系结构
  • 3.1. Core Container
    • 3.1.1. BeanFactory
    • 3.1.2. ApplicationContext
  • 3.2. AOP and Instrumentation
  • 3.3. Messaging
  • 3.4. Data Access / Integaration
  • 3.5. Web
  • 3.6. Test
• 4. 术语

Spring 框架提供了非常丰富的功能，因此整个架构也很庞大。
在我们实际的应用开发中，并不一定要使用所有的功能，而是可以根据需要选择合适的 Spring 模块。

Core Container

IoC 容器是 Spring 框架的核心。spring 容器使用依赖注入管理构成应用的组件，它会创建相互协作的组件之间的关联。毫无疑问，这些对象更简单干净，更容易理解，也更容易重用和测试。
Spring 自带了几种容器的实现，可归纳为两种类型：

BeanFactory

由 org.springframework.beans.factory.BeanFactory 接口定义。
它是最简单的容器，提供基本的 DI 支持。

ApplicationContext

由 org.springframework.context.ApplicationContext 接口定义。
它是基于 BeanFactory 之上构建，并提供面向应用的服务，例如从属性文件解析文本信息的能力，以及发布应用事件给感兴趣的事件监听者的能力。
注：Bean 工厂对于大多数应用来说往往太低级了，所以应用上下文使用更广泛。推荐在开发中使用应用上下文容器。

Spring 自带了多种应用上下文，最可能遇到的有以下几种：
ClassPathXmlApplicationContext：从类路径下的 XML 配置文件中加载上下文定义，把应用上下文定义文件当做类资源。
FileSystemXmlApplicationContext：读取文件系统下的 XML 配置文件并加载上下文定义。
XmlWebApplicationContext：读取 Web 应用下的 XML 配置文件并装载上下文定义。

范例

1
2

ApplicationContext context = new FileSystemXmlApplicationContext("D:\Temp\build.xml");
ApplicationContext context2 = new ClassPathXmlApplicationContext("build.xml");

可以看到，加载 FileSystemXmlApplicationContext 和 ClassPathXmlApplicationContext 十分相似。
差异在于：前者在指定文件系统路径下查找 build.xml 文件；而后在所有类路径（包含 JAR 文件）下查找 build.xml 文件。
通过引用应用上下文，可以很方便的调用 getBean() 方法从 Spring 容器中获取 Bean。

相关 jar 包

• spring-core, spring-beans, 提供框架的基础部分，包括 IoC 和依赖注入特性。

• spring-context, 在spring-core, spring-beans基础上构建。它提供一种框架式的访问对象的方法。它也支持类似 Java EE 特性，例如：EJB，JMX 和基本 remoting。ApplicationContext 接口是它的聚焦点。

• springcontext-support, 集成第三方库到 Spring application context。

• spring-expression，提供一种强有力的表达语言在运行时来查询和操纵一个对象图。

AOP and Instrumentation

相关 jar 包

• spring-aop，提供了对面向切面编程的丰富支持。
• spring-aspects，提供了对 AspectJ 的集成。
• spring-instrument，提供了对类 instrumentation 的支持和类加载器。
• spring-instrument-tomcat，包含了 Spring 对 Tomcat 的 instrumentation 代理。

Messaging

相关 jar 包

• spring-messaging，包含 spring 的消息处理功能，如 Message，MessageChannel，MessageHandler。

Data Access / Integaration

Data Access/Integration 层包含了 JDBC / ORM / OXM / JMS 和 Transaction 模块。

相关 jar 包

• spring-jdbc，提供了一个 JDBC 抽象层。

• spring-tx，支持编程和声明式事务管理类。

• spring-orm，提供了流行的对象关系型映射 API 集，如 JPA，JDO，Hibernate。

• spring-oxm，提供了一个抽象层以支持对象/XML 映射的实现，如 JAXB，Castor，XMLBeans，JiBX 和 XStream.

• spring-jms，包含了生产和消费消息的功能。

Web

相关 jar 包

• spring-web，提供了基本的面向 web 的功能，如多文件上传、使用 Servlet 监听器的 Ioc 容器的初始化。一个面向 web 的应用层上下文。

• spring-webmvc，包括 MVC 和 REST web 服务实现。

• spring-webmvc-portlet，提供在 Protlet 环境的 MVC 实现和spring-webmvc功能的镜像。

Test

相关 jar 包

• spring-test，以 Junit 和 TestNG 来支持 spring 组件的单元测试和集成测试。

术语

• 应用程序：是能完成我们所需要功能的成品，比如购物网站、OA 系统。
• 框架：是能完成一定功能的半成品，比如我们可以使用框架进行购物网站开发；框架做一部分功能，我们自己做一部分功能，这样应用程序就创建出来了。而且框架规定了你在开发应用程序时的整体架构，提供了一些基础功能，还规定了类和对象的如何创建、如何协作等，从而简化我们开发，让我们专注于业务逻辑开发。
• 非侵入式设计：从框架角度可以这样理解，无需继承框架提供的类，这种设计就可以看作是非侵入式设计，如果继承了这些框架类，就是侵入设计，如果以后想更换框架之前写过的代码几乎无法重用，如果非侵入式设计则之前写过的代码仍然可以继续使用。
• 轻量级及重量级：轻量级是相对于重量级而言的，轻量级一般就是非入侵性的、所依赖的东西非常少、资源占用非常少、部署简单等等，其实就是比较容易使用，而重量级正好相反。
• POJO：POJO（Plain Old Java Objects）简单的 Java 对象，它可以包含业务逻辑或持久化逻辑，但不担当任何特殊角色且不继承或不实现任何其它 Java 框架的类或接口。
• 容器：在日常生活中容器就是一种盛放东西的器具，从程序设计角度看就是装对象的的对象，因为存在放入、拿出等操作，所以容器还要管理对象的生命周期。
• 控制反转：即 Inversion of Control，缩写为 IoC，控制反转还有一个名字叫做依赖注入（Dependency Injection），就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。
• JavaBean：一般指容器管理对象，在 Spring 中指 Spring IoC 容器管理对象。

计算机网络面试总结

如果你不是从事于通信领域，面试时问及计算机网络的知识，一般也就限定在：HTTP（含 HTTPS、Cookie、Session）、TCP、UDP、Socket 这些

综合

计算机网络如何分层？

❓ 问题：计算机网络如何分层？各层的作用是什么？各层的主要协议、设备分别是什么？

这是学习计算机网络知识宏观层面必须要了解的核心点。知道了这些，对于网络的体系结构就基本上了解了。

计算机网络分层一般有三种划分体系：OSI 分层；五层协议分层；TCP/IP 协议分层。

• OSI 的七层体系结构概念清楚，理论完整，但是比较复杂且不实用，所以并不流行。
• 五层协议分层是一种折中方案，在现实中更为流行。

物理层

物理层（Physical Layer）只接收和发送一串比特(bit)流，不考虑信息的意义和信息结构。

扩展阅读：计算机网络之物理层

• 关键词：调制、解调、数字信号、模拟信号、通信媒介、信道复用
• 数据单元：比特流。
• 典型设备：光纤、同轴电缆、双绞线、中继器和集线器。

数据链路层

网络层针对的还是主机之间的数据传输服务，而主机之间可以有很多链路，数据链路层（Data Link Layer）就是为同一链路的主机提供数据传输服务。数据链路层把网络层传下来的分组封装成帧。

扩展阅读：计算机网络之数据链路层

• 关键词：点对点信道、广播信道、PPP、CSMA/CD、局域网、以太网、MAC、适配器、集线器、网桥、交换机
• 主要协议：PPP、CSMA/CD 等。
• 数据单元：帧（frame）。
• 典型设备：二层交换机、网桥、网卡。

网络层

网络层（network layer）为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包进行传送。

扩展阅读：计算机网络之网络层

• 关键词：IP、ICMP、ARP、路由
• 主要协议：IP。
• 数据单元：IP 数据报（packet）。
• 典型设备：网关、路由器。

传输层

传输层（transport layer）为两台主机中进程间的通信提供通用的数据传输服务。

扩展阅读：计算机网络之传输层

• 关键词：UDP、TCP、滑动窗口、拥塞控制、三次握手
• 主要协议：TCP、UDP。
• 数据单元：报文段（segment）或用户数据报。

\会话层~~

~~会话层（Session Layer）不参与具体的传输，它提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制。~~

\表示层~~

~~表示层（Presentation Layer）是为在应用过程之间传送的信息提供表示方法的服务，它关心的只是发出信息的语法与语义。表示层要完成某些特定的功能，主要有不同数据编码格式的转换，提供数据压缩、解压缩服务，对数据进行加密、解密。~~

应用层

应用层（application layer）通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。

扩展阅读：计算机网络之应用层

• 关键词：HTTP、DNS、FTP、TELNET、DHCP
• 主要协议：HTTP、DNS、SMTP、Telnet、FTP、SNMP 等。
• 数据单元：报文（message）。

HTTP

扩展阅读：超文本传输协议 HTTP

DNS

扩展阅读：域名系统协议 DNS

TCP/UDP

扩展阅读：传输控制协议 TCP，用户数据报协议 UDP

什么是 TCP？

TCP（Transmission Control Protocol），即传输控制协议，它是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP 的特性是什么？

• 面向连接的 - 面向连接是指 TCP 需要通过三次握手、四次挥手原则建立和断开双向连接。
• 可靠的 - 可靠是指 TCP 传输的数据包保证以原始顺序到达目的地，且数据包不被损坏。为了实现这点，TCP 通过以下技术来保证：
  • 数据包的序列号和校验码
  • 确认包和自动重传
    • 如果发送者没有收到正确的响应，它将重新发送数据包。如果多次超时，连接就会断开。
    • TCP 实行流量控制和拥塞控制。这些确保措施会导致延迟，而且通常导致传输效率比 UDP 低。
• 基于字节流的
  • 虽然应用程序和 TCP 的交互是一次一个数据块（大小不等），但 TCP 把应用程序看成是一连串的无结构的字节流。TCP 有一个缓冲，当应用程序传送的数据块太长，TCP 就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP 也可以等待积累有足够多的字节后再构成报文段发送出去。
  • 在 TCP 建立连接前两次握手的 SYN 报文中选项字段的 MSS 值，通信双方商定通信的最大报文长度。如果应用层交付下来的数据过大，就会对数据分段，然后发送；否则通过滑动窗口来控制通信双发的数据。

TCP 三次握手

❓ 问题：三次握手有什么用？什么是三次握手？为什么需要三次握手？

（1）三次握手有什么用？

• 三次握手负责建立 TCP 双向连接。

（2）什么是三次握手？

如上图所示，三次握手流程如下：

1. 第一次握手 - 客户端向服务端发送带有 SYN 标志的数据包。
2. 第二次握手 - 服务端向客户端发送带有 SYN/ACK 标志的数据包。
3. 第三次握手 - 客户端向服务端发送带有带有 ACK 标志的数据包。

至此，TCP 三次握手完成，客户端与服务端已建立双向连接。

💡 说明：SYN 为 synchronize 的缩写，ACK 为 acknowledgment 的缩写。

（3）为什么需要三次握手？

为了便于说明，假设客户端为 A, 服务端为 B。

1. 第一次握手，A 向 B 发同步消息。B 收到消息后，B 认为：A 发消息没问题；B 收消息没问题。
2. 第二次握手，B 向 A 发同步消息和确认消息。A 收到消息后，A 认为：A 发消息、收消息都没问题；B 发消息、收消息都没问题。但是，此时 B 不确定自己发消息是否没问题，所以就需要第三次握手。
3. 第三次握手，A 向 B 发确认消息。B 收到消息后。B 认为：B 发消息没问题。

TCP 四次挥手

❓ 问题：四次挥手有什么用？什么是四次挥手？为什么建立连接是三次握手，关闭连接确是四次挥手呢？

（1）四次挥手有什么用？

• 四次挥手负责断开 TCP 连接。

（2）什么是四次挥手？

如上图所示，四次挥手流程如下：

1. 第一次挥手 - 客户端向服务端发送一个 FIN 包，用来关闭客户端到服务端的数据传送。
2. 第二次挥手 - 服务端收到这个 FIN 包，向客户端发送一个 ACK 包，确认序号为收到的序号加 1。和 SYN 一样，一个 FIN 将占用一个序号。
3. 第三次挥手 - 服务端关闭与客户端的连接，向客户端发送一个 FIN 包。
4. 第四次挥手 - 客户端向服务端发送 ACK 包，并将确认序号设置为收到序号加 1。

（3）为什么建立连接是三次握手，关闭连接确是四次挥手呢？

• 建立连接的时候， 服务器在 LISTEN 状态下，收到建立连接请求的 SYN 报文后，把 ACK 和 SYN 放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的 FIN 报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送 FIN 报文给对方来表示同意现在关闭连接，因此，己方 ACK 和 FIN 一般都会分开发送，从而导致多了一次。

TCP 滑动窗口

❓ 问题：什么是滑动窗口？滑动窗口原理是什么？

什么是滑动窗口？

滑动窗口是 TCP 的一种控制网络流量的技术。

TCP 必需要解决的可靠传输以及包乱序（reordering）的问题，所以，TCP 必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包。

TCP 头里有一个字段叫 Window，又叫 Advertised-Window，这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

滑动窗口原理是什么？

1. 已发送已确认 - 数据流中最早的字节已经发送并得到确认。这些数据是站在发送端的角度来看的。上图中的 31 个字节已经发送并确认。
2. 已发送但尚未确认 - 已发送但尚未得到确认的字节。发送方在确认之前，不认为这些数据已经被处理。上图中的 32 ~ 45 字节为第 2 类。
3. 未发送而接收方已 Ready - 设备尚未将数据发出 ，但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。上图中的 46 ~ 51 字节为第 3 类。
4. 未发送而接收方 Not Ready - 由于接收方 not ready，还不允许将这部分数据发出。上图中的 52 以后的字节为第 4 类。

这张图片相对于上一张图片，滑动窗口偏移了 5 个字节，意味着有 5 个已发送的字节得到了确认。

TCP 重传机制

❓ 问题：为什么需要重传机制？TCP 有哪些重传机制，原理是什么？

TCP 要保证所有的数据包都可以到达，所以，必需要有重传机制。

TCP 重传机制主要有两种：

• 超时重传机制
• 快速重传机制

（1）超时重传机制

超时重传机制是指：发送数据包在一定的时间周期内没有收到相应的 ACK，等待一定的时间，超时之后就认为这个数据包丢失，就会重新发送。这个等待时间被称为 RTO(Retransmission TimeOut)，即重传超时时间。

没有确认的数据包不会从窗口中移走，定时器在重传时间到期内，每个片段的位置不变。

这种机制的重点是 RTO 的设置：

• RTO 设长了，重发就慢，丢了老半天才重发，没有效率，性能差；
• RTO 设短了，会导致可能并没有丢就重发。于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发

（2）快速重传机制

快速重传机制，实现了另外的一种丢包评定标准，即如果连续收到 3 次重复 ACK，发送方就认为这个 seq 的包丢失了，立刻进行重传。

当接收方收到乱序片段时，需要重复发送 ACK。

SpringBoot 之发送邮件

简介

Spring Boot 收发邮件最简便方式是通过 spring-boot-starter-mail。

1
2
3
4

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-mail</artifactId>
</dependency>

spring-boot-starter-mail 本质上是使用 JavaMail(javax.mail)。如果想对 JavaMail 有进一步了解，可以参考： JavaMail 使用指南

API

Spring Framework 提供了一个使用 JavaMailSender 接口发送电子邮件的简单抽象，这是发送邮件的核心 API。

JavaMailSender 接口提供的 API 如下：

配置

Spring Boot 为 JavaMailSender 提供了自动配置以及启动器模块。

如果 spring.mail.host 和相关库（由 spring-boot-starter-mail 定义）可用，则 Spring Boot 会创建默认 JavaMailSender（如果不存在）。可以通过 spring.mail 命名空间中的配置项进一步自定义发件人。
特别是，某些默认超时值是无限的，您可能希望更改它以避免线程被无响应的邮件服务器阻塞，如以下示例所示：

1
2
3

spring.mail.properties.mail.smtp.connectiontimeout=5000
spring.mail.properties.mail.smtp.timeout=3000
spring.mail.properties.mail.smtp.writetimeout=5000

也可以使用 JNDI 中的现有会话配置 JavaMailSender：

1

spring.mail.jndi-name=mail/Session

以下为 Spring Boot 关于 Mail 的配置：

有关更多详细信息，请参阅 MailProperties。

1
2
3
4
5
6
7
8
9
10

# Email (MailProperties)
spring.mail.default-encoding=UTF-8 # Default MimeMessage encoding.
spring.mail.host= # SMTP server host. For instance, `smtp.example.com`.
spring.mail.jndi-name= # Session JNDI name. When set, takes precedence over other Session settings.
spring.mail.password= # Login password of the SMTP server.
spring.mail.port= # SMTP server port.
spring.mail.properties.*= # Additional JavaMail Session properties.
spring.mail.protocol=smtp # Protocol used by the SMTP server.
spring.mail.test-connection=false # Whether to test that the mail server is available on startup.
spring.mail.username= # Login user of the SMTP server.

实战

引入依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-mail</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
  </dependency>

  <dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
  </dependency>
  <dependency>
    <groupId>com.github.dozermapper</groupId>
    <artifactId>dozer-spring-boot-starter</artifactId>
    <version>6.4.0</version>
  </dependency>
</dependencies>

配置邮件属性

在 src/main/resources 目录下添加 application-163.properties 配置文件，内容如下：

1
2
3
4
5
6
7
8
9
10

spring.mail.host = smtp.163.com
spring.mail.username = xxxxxx
spring.mail.password = xxxxxx
spring.mail.properties.mail.smtp.auth = true
spring.mail.properties.mail.smtp.starttls.enable = true
spring.mail.properties.mail.smtp.starttls.required = true
spring.mail.default-encoding = UTF-8

mail.domain = 163.com
mail.from = ${spring.mail.username}@${mail.domain}

注：需替换有效的 spring.mail.username、spring.mail.password。

application-163.properties 配置文件表示使用 163 邮箱时的配置，为了使之生效，需要通过 spring.profiles.active = 163 来激活它。

在 src/main/resources 目录下添加 application.properties 配置文件，内容如下：

1

spring.profiles.active = 163

Java 代码

首先，需要读取部分配置属性，方法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
import org.springframework.validation.annotation.Validated;

@Validated
@Component
@ConfigurationProperties(prefix = "mail")
public class MailProperties {
    private String domain;
    private String from;

    public String getDomain() {
        return domain;
    }

    public void setDomain(String domain) {
        this.domain = domain;
    }

    public String getFrom() {
        return from;
    }

    public void setFrom(String from) {
        this.from = from;
    }
}

接着，定义一个邮件参数实体类（使用 lombok 简化了 getter、setter）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import lombok.Data;
import java.util.Date;

@Data
public class MailDTO {
    private String from;
    private String replyTo;
    private String[] to;
    private String[] cc;
    private String[] bcc;
    private Date sentDate;
    private String subject;
    private String text;
    private String[] filenames;
}

接着，实现发送邮件的功能接口：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

import com.github.dozermapper.core.Mapper;
import org.apache.commons.lang3.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.mail.SimpleMailMessage;
import org.springframework.mail.javamail.JavaMailSender;
import org.springframework.mail.javamail.MimeMessageHelper;
import org.springframework.stereotype.Service;

import javax.mail.MessagingException;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;
import java.io.IOException;

@Service
public class MailService {

    private final Logger log = LoggerFactory.getLogger(this.getClass());

    @Autowired
    private MailProperties mailProperties;

    @Autowired
    private JavaMailSender javaMailSender;

    @Autowired
    private Mapper mapper;

    public void sendSimpleMailMessage(MailDTO mailDTO) {
        SimpleMailMessage simpleMailMessage = mapper.map(mailDTO, SimpleMailMessage.class);
        if (StringUtils.isEmpty(mailDTO.getFrom())) {
            mailDTO.setFrom(mailProperties.getFrom());
        }
        javaMailSender.send(simpleMailMessage);
    }

    public void sendMimeMessage(MailDTO mailDTO) {

        MimeMessage mimeMessage = javaMailSender.createMimeMessage();
        MimeMessageHelper messageHelper;
        try {
            messageHelper = new MimeMessageHelper(mimeMessage, true);

            if (StringUtils.isEmpty(mailDTO.getFrom())) {
                messageHelper.setFrom(mailProperties.getFrom());
            }
            messageHelper.setTo(mailDTO.getTo());
            messageHelper.setSubject(mailDTO.getSubject());

            mimeMessage = messageHelper.getMimeMessage();
            MimeBodyPart mimeBodyPart = new MimeBodyPart();
            mimeBodyPart.setContent(mailDTO.getText(), "text/html;charset=UTF-8");

            // 描述数据关系
            MimeMultipart mm = new MimeMultipart();
            mm.setSubType("related");
            mm.addBodyPart(mimeBodyPart);

            // 添加邮件附件
            for (String filename : mailDTO.getFilenames()) {
                MimeBodyPart attachPart = new MimeBodyPart();
                try {
                    attachPart.attachFile(filename);
                } catch (IOException e) {
                    e.printStackTrace();
                }
                mm.addBodyPart(attachPart);
            }
            mimeMessage.setContent(mm);
            mimeMessage.saveChanges();

        } catch (MessagingException e) {
            e.printStackTrace();
        }

        javaMailSender.send(mimeMessage);
    }
}

示例源码

示例源码：spring-boot-mail

参考资料

• Spring Boot 官方文档之 Sending Email

SpringBoot 之 Profile

一个应用为了在不同的环境下工作，常常会有不同的配置，代码逻辑处理。Spring Boot 对此提供了简便的支持。

关键词： @Profile、spring.profiles.active

区分环境的配置

properties 配置

假设，一个应用的工作环境有：dev、test、prod

那么，我们可以添加 4 个配置文件：

• applcation.properties - 公共配置
• application-dev.properties - 开发环境配置
• application-test.properties - 测试环境配置
• application-prod.properties - 生产环境配置

在 applcation.properties 文件中可以通过以下配置来激活 profile：

1

spring.profiles.active = test

yml 配置

与 properties 文件类似，我们也可以添加 4 个配置文件：

• applcation.yml - 公共配置
• application-dev.yml - 开发环境配置
• application-test.yml - 测试环境配置
• application-prod.yml - 生产环境配置

在 applcation.yml 文件中可以通过以下配置来激活 profile：

1
2
3

spring:
  profiles:
    active: prod

此外，yml 文件也可以在一个文件中完成所有 profile 的配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 激活 prod
spring:
  profiles:
    active: prod
# 也可以同时激活多个 profile
# spring.profiles.active: prod,proddb,prodlog
---
# dev 配置
spring:
  profiles: dev

# 略去配置

---
spring:
  profiles: test

# 略去配置

---
spring.profiles: prod
spring.profiles.include:
  - proddb
  - prodlog

---
spring:
  profiles: proddb

# 略去配置

---
spring:
  profiles: prodlog
# 略去配置

注意：不同 profile 之间通过 --- 分割

区分环境的代码

使用 @Profile 注解可以指定类或方法在特定的 Profile 环境生效。

修饰类

1
2
3
4
5
6
7
8
9
10

@Configuration
@Profile("production")
public class JndiDataConfig {

    @Bean(destroyMethod="")
    public DataSource dataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}

修饰注解

1
2
3
4
5

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Profile("production")
public @interface Production {
}

修饰方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Configuration
public class AppConfig {

    @Bean("dataSource")
    @Profile("development")
    public DataSource standaloneDataSource() {
        return new EmbeddedDatabaseBuilder()
            .setType(EmbeddedDatabaseType.HSQL)
            .addScript("classpath:com/bank/config/sql/schema.sql")
            .addScript("classpath:com/bank/config/sql/test-data.sql")
            .build();
    }

    @Bean("dataSource")
    @Profile("production")
    public DataSource jndiDataSource() throws Exception {
        Context ctx = new InitialContext();
        return (DataSource) ctx.lookup("java:comp/env/jdbc/datasource");
    }
}

激活 profile

插件激活 profile

1

spring-boot:run -Drun.profiles=prod

main 方法激活 profile

1

--spring.profiles.active=prod

jar 激活 profile

1

java -jar -Dspring.profiles.active=prod *.jar

在 Java 代码中激活 profile

直接指定环境变量来激活 profile：

1

System.setProperty("spring.profiles.active", "test");

在 Spring 容器中激活 profile：

1
2
3
4

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("development");
ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
ctx.refresh();

示例源码

示例源码：spring-boot-profile

参考资料

• Spring 官方文档之 Bean Definition Profiles
• Spring Boot 官方文档之 boot-features-profiles

SpringBoot 教程之处理异步请求

@EnableAsync 注解

要使用 @Async，首先需要使用 @EnableAsync 注解开启 Spring Boot 中的异步特性。

1
2
3
4

@Configuration
@EnableAsync
public class AppConfig {
}

更详细的配置说明，可以参考：AsyncConfigurer

@Async 注解

支持的用法

（1）无入参无返回值方法

您可以用 @Async 注解修饰方法，这表明这个方法是异步方式调用。换句话说，程序在调用此方法时会立即返回，而方法的实际执行发生在已提交给 Spring TaskExecutor 的任务中。在最简单的情况下，您可以将注解应用于返回 void 的方法，如以下示例所示：

1
2
3
4

@Async
void doSomething() {
    // this will be executed asynchronously
}

（2）有入参无返回值方法

与使用 @Scheduled 注释注释的方法不同，这些方法可以指定参数，因为它们在运行时由调用者以“正常”方式调用，而不是由容器管理的调度任务调用。例如，以下代码是 @Async 注解的合法应用：

1
2
3
4

@Async
void doSomething(String s) {
    // this will be executed asynchronously
}

（3）有入参有返回值方法

甚至可以异步调用返回值的方法。但是，这些方法需要具有 Future 类型的返回值。这仍然提供了异步执行的好处，以便调用者可以在调用 Future 上的 get() 之前执行其他任务。以下示例显示如何在返回值的方法上使用@Async：

1
2
3
4

@Async
Future<String> returnSomething(int i) {
    // this will be executed asynchronously
}

不支持的用法

@Async 不能与生命周期回调一起使用，例如 @PostConstruct。

要异步初始化 Spring bean，必须使用单独的初始化 Spring bean，然后在目标上调用 @Async 带注释的方法，如以下示例所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class SampleBeanImpl implements SampleBean {

    @Async
    void doSomething() {
        // ...
    }

}

public class SampleBeanInitializer {

    private final SampleBean bean;

    public SampleBeanInitializer(SampleBean bean) {
        this.bean = bean;
    }

    @PostConstruct
    public void initialize() {
        bean.doSomething();
    }

}

明确指定执行器

默认情况下，在方法上指定 @Async 时，使用的执行器是在启用异步支持时配置的执行器，即如果使用 XML 或 AsyncConfigurer 实现（如果有），则为 annotation-driven 元素。但是，如果需要指示在执行给定方法时应使用默认值以外的执行器，则可以使用 @Async 注解的 value 属性。以下示例显示了如何执行此操作：

1
2
3
4

@Async("otherExecutor")
void doSomething(String s) {
    // this will be executed asynchronously by "otherExecutor"
}

在这种情况下，“otherExecutor”可以是 Spring 容器中任何 Executor bean 的名称，也可以是与任何 Executor 关联的限定符的名称（例如，使用 <qualifier> 元素或 Spring 的 @Qualifier 注释指定） ）。

管理 @Async 的异常

当 @Async 方法的返回值类型为 Future 型时，很容易管理在方法执行期间抛出的异常，因为在调用 get 结果时会抛出此异常。但是，对于返回值类型为 void 型的方法，异常不会被捕获且无法传输。您可以提供 AsyncUncaughtExceptionHandler 来处理此类异常。以下示例显示了如何执行此操作：

1
2
3
4
5
6
7

public class MyAsyncUncaughtExceptionHandler implements AsyncUncaughtExceptionHandler {

    @Override
    public void handleUncaughtException(Throwable ex, Method method, Object... params) {
        // handle exception
    }
}

默认情况下，仅记录异常。您可以使用 AsyncConfigurer 或 <task：annotation-driven /> XML 元素定义自定义 AsyncUncaughtExceptionHandler。

示例源码

示例源码：spring-boot-async

参考资料

• Spring Boot 官方文档之 boot-features-external-config
• Spring Boot 官方文档之 scheduling-annotation-support

Java 虚拟机之字节码

字节码简介

Java 字节码是 Java 虚拟机执行的一种指令格式。之所以被称之为字节码，是因为：Java 字节码文件（.class）是一种以 8 位字节为基础单位的二进制流文件，各个数据项严格按照顺序紧凑地排列在 .class 文件中，中间没有添加任何分隔符。整个 .class 文件本质上就是一张表。

Java 能做到 “一次编译，到处运行”，一是因为 JVM 针对各种操作系统、平台都进行了定制；二是因为无论在什么平台，都可以编译生成固定格式的 Java 字节码文件（.class）。

类文件结构

一个 Java 类编译后生成的 .class 文件内容如下图所示，是一堆十六进制数。

Class 文件是一组以 8 个字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在文 件之中，中间没有添加任何分隔符，这使得整个 Class 文件中存储的内容几乎全部是程序运行的必要数 据，没有空隙存在。

图来自 字节码增强技术探索

字节码看似杂乱无序，实际上是由严格的格式要求组成的。

魔数

每个 .class 文件的头 4 个字节称为 **魔数（magic_number）**，它的唯一作用是确定这个文件是否为一个能被虚拟机接收的 .class 文件。魔数的固定值为：0xCAFEBABE（咖啡宝贝）。

版本号

版本号（version）有 4 个字节，前两个字节表示次版本号（Minor Version），后两个字节表示主版本号（Major Version）。

Java 的版本号是从 45 开始的，JDK 1.1 之后 的每个 JDK 大版本发布主版本号向上加 1。举例来说，如果版本号为：“00 00 00 34”。那么，次版本号转化为十进制为 0，主版本号转化为十进制为 52，在 Oracle 官网中查询序号 52 对应的主版本号为 1.8，所以编译该文件的 Java 版本号为 1.8.0。

常量池

紧接着主版本号之后的字节为常量池（constant_pool），常量池可以理解为 .class 文件中的资源仓库。

常量池整体上分为两部分：常量池计数器以及常量池数据区

• 常量池计数器（constant_pool_count） - 由于常量的数量不固定，所以需要先放置两个字节来表示常量池容量计数值。

• 常量池数据区 - 数据区的每一项常量都是一个表，且结构各不相同。

常量池主要存放两类常量：

• 字面量 - 如文本字符串、声明为 final 的常量值。
• 符号引用
  • 类和接口的全限定名
  • 字段的名称和描述符
  • 方法的名称和描述符

访问标志

紧接着常量池的 2 个字节代表访问标志（access_flags），这个标志用于识别一些类或者接口的访问信息，描述该 Class 是类还是接口；以及是否被 public、abstract、final 等修饰符修饰。

类索引、父类索引、接口索引集合

类索引（this_class）和父类索引都是一个 u2 类型的数据，而接口索引集合是一组 u2 类型的数据的集合，Class 文件中由这三项数据来确定该类型的继承关系。

字段表集合

字段表（field_info）用于描述类和接口中声明的变量。Java 语言中的“字段”（Field）包括类级变 量以及实例级变量，但不包括在方法内部声明的局部变量。

字段可以包括的修饰符有字段的作用域（public、private、protected 修饰 符）、是实例变量还是类变量（static 修饰符）、可变性（final）、并发可见性（volatile 修饰符，是否 强制从主内存读写）、可否被序列化（transient 修饰符）、字段数据类型（基本类型、对象、数组）、 字段名称。

方法表集合

Class 文件存储 格式中对方法的描述与对字段的描述采用了几乎完全一致的方式，方法表的结构如同字段表一样，依 次包括访问标志（access_flags）、名称索引（name_index）、描述符索引（descriptor_index）、属性表 集合（attributes）几项

字段表结束后为方法表，方法表的结构如同字段表一样，依次包括了访问标志、名称索引、描述符索引、属性表集合几项。

属性表集合

属性表集合（attribute_info）存放了在该文件中类或接口所定义属性的基本信息。

字节码指令

字节码指令由一个字节长度的、代表着某种特定操作含义的数字（称为操作码，Opcode）以及跟随其后的零到多个代表此操作所需参数（Operands）而构成。由于 JVM 采用面向操作数栈架构而不是寄存器架构，所以大多数的指令都不包括操作数，只有一个操作码。

JVM 操作码的长度为 1 个字节，因此指令集的操作码最多只有 256 个。

字节码操作大致分为 9 类：

• 加载和存储指令
• 运算指令
• 类型转换指令
• 对象创建与访问指令
• 操作数栈管理指令
• 控制转移指令
• 方法调用和返回指令
• 异常处理指令
• 同步指令

字节码增强

Asm

对于需要手动操纵字节码的需求，可以使用 Asm，它可以直接生产 .class字节码文件，也可以在类被加载入 JVM 之前动态修改类行为（如下图 17 所示）。

Asm 的应用场景有 AOP（Cglib 就是基于 Asm）、热部署、修改其他 jar 包中的类等。当然，涉及到如此底层的步骤，实现起来也比较麻烦。

Asm 有两类 API：核心 API 和树形 API

核心 API

Asm Core API 可以类比解析 XML 文件中的 SAX 方式，不需要把这个类的整个结构读取进来，就可以用流式的方法来处理字节码文件。好处是非常节约内存，但是编程难度较大。然而出于性能考虑，一般情况下编程都使用 Core API。在 Core API 中有以下几个关键类：

• ClassReader：用于读取已经编译好的。class 文件。
• ClassWriter：用于重新构建编译后的类，如修改类名、属性以及方法，也可以生成新的类的字节码文件。
• 各种 Visitor 类：如上所述，CoreAPI 根据字节码从上到下依次处理，对于字节码文件中不同的区域有不同的 Visitor，比如用于访问方法的 MethodVisitor、用于访问类变量的 FieldVisitor、用于访问注解的 AnnotationVisitor 等。为了实现 AOP，重点要使用的是 MethodVisitor。

树形 API

Asm Tree API 可以类比解析 XML 文件中的 DOM 方式，把整个类的结构读取到内存中，缺点是消耗内存多，但是编程比较简单。TreeApi 不同于 CoreAPI，TreeAPI 通过各种 Node 类来映射字节码的各个区域，类比 DOM 节点，就可以很好地理解这种编程方式。

Javassist

利用 Javassist 实现字节码增强时，可以无须关注字节码刻板的结构，其优点就在于编程简单。直接使用 java 编码的形式，而不需要了解虚拟机指令，就能动态改变类的结构或者动态生成类。

其中最重要的是 ClassPool、CtClass、CtMethod、CtField 这四个类：

• CtClass（compile-time class） - 编译时类信息，它是一个 class 文件在代码中的抽象表现形式，可以通过一个类的全限定名来获取一个 CtClass 对象，用来表示这个类文件。
• ClassPool - 从开发视角来看，ClassPool 是一张保存 CtClass 信息的 HashTable，key 为类名，value 为类名对应的 CtClass 对象。当我们需要对某个类进行修改时，就是通过 pool.getCtClass(“className”) 方法从 pool 中获取到相应的 CtClass。
• CtMethod、CtField - 这两个比较好理解，对应的是类中的方法和属性。

参考资料

• 《深入理解 Java 虚拟机》
• 字节码增强技术探索
• 一文让你明白 Java 字节码
• Asm 4.0 官方文档
• Javassist Github

Java 虚拟机之调优

JVM 调优概述

GC 性能指标

对于 JVM 调优来说，需要先明确调优的目标。
从性能的角度看，通常关注三个指标：

• 吞吐量（throughput） - 指不考虑 GC 引起的停顿时间或内存消耗，垃圾收集器能支撑应用达到的最高性能指标。
• 停顿时间（latency） - 其度量标准是缩短由于垃圾啊收集引起的停顿时间或者完全消除因垃圾收集所引起的停顿，避免应用运行时发生抖动。
• 垃圾回收频率 - 久发生一次指垃圾回收呢？通常垃圾回收的频率越低越好，增大堆内存空间可以有效降低垃圾回收发生的频率，但同时也意味着堆积的回收对象越多，最终也会增加回收时的停顿时间。所以我们只要适当地增大堆内存空间，保证正常的垃圾回收频率即可。

大多数情况下调优会侧重于其中一个或者两个方面的目标，很少有情况可以兼顾三个不同的角度。

调优原则

GC 优化的两个目标：

• 降低 Full GC 的频率
• 减少 Full GC 的执行时间

GC 优化的基本原则是：将不同的 GC 参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少 GC 执行时间的参数应用于最终的工作服务器上。

降低 Minor GC 频率

如果新生代空间较小，Eden 区很快被填满，就会导致频繁 Minor GC，因此我们可以通过增大新生代空间来降低 Minor GC 的频率。

可能你会有这样的疑问，扩容 Eden 区虽然可以减少 Minor GC 的次数，但不会增加单次 Minor GC 的时间吗？如果单次 Minor GC 的时间增加，那也很难达到我们期待的优化效果呀。

我们知道，单次 Minor GC 时间是由两部分组成：T1（扫描新生代）和 T2（复制存活对象）。假设一个对象在 Eden 区的存活时间为 500ms，Minor GC 的时间间隔是 300ms，那么正常情况下，Minor GC 的时间为 ：T1+T2。

当我们增大新生代空间，Minor GC 的时间间隔可能会扩大到 600ms，此时一个存活 500ms 的对象就会在 Eden 区中被回收掉，此时就不存在复制存活对象了，所以再发生 Minor GC 的时间为：两次扫描新生代，即 2T1。

可见，扩容后，Minor GC 时增加了 T1，但省去了 T2 的时间。通常在虚拟机中，复制对象的成本要远高于扫描成本。

如果在堆内存中存在较多的长期存活的对象，此时增加年轻代空间，反而会增加 Minor GC 的时间。如果堆中的短期对象很多，那么扩容新生代，单次 Minor GC 时间不会显著增加。因此，单次 Minor GC 时间更多取决于 GC 后存活对象的数量，而非 Eden 区的大小。

降低 Full GC 的频率

Full GC 相对来说会比 Minor GC 更耗时。减少进入老年代的对象数量可以显著降低 Full GC 的频率。

减少创建大对象：如果对象占用内存过大，在 Eden 区被创建后会直接被传入老年代。在平常的业务场景中，我们习惯一次性从数据库中查询出一个大对象用于 web 端显示。例如，我之前碰到过一个一次性查询出 60 个字段的业务操作，这种大对象如果超过年轻代最大对象阈值，会被直接创建在老年代；即使被创建在了年轻代，由于年轻代的内存空间有限，通过 Minor GC 之后也会进入到老年代。这种大对象很容易产生较多的 Full GC。

我们可以将这种大对象拆解出来，首次只查询一些比较重要的字段，如果还需要其它字段辅助查看，再通过第二次查询显示剩余的字段。

增大堆内存空间：在堆内存不足的情况下，增大堆内存空间，且设置初始化堆内存为最大堆内存，也可以降低 Full GC 的频率。

降低 Full GC 的时间

Full GC 的执行时间比 Minor GC 要长很多，因此，如果在 Full GC 上花费过多的时间（超过 1s），将可能出现超时错误。

• 如果通过减小老年代内存来减少 Full GC 时间，可能会引起 OutOfMemoryError 或者导致 Full GC 的频率升高。
• 另外，如果通过增加老年代内存来降低 Full GC 的频率，Full GC 的时间可能因此增加。

因此，你需要把老年代的大小设置成一个“合适”的值。

GC 优化需要考虑的 JVM 参数

GC 优化时最常用的参数是-Xms,-Xmx和-XX:NewRatio。-Xms和-Xmx参数通常是必须的，所以NewRatio的值将对 GC 性能产生重要的影响。

有些人可能会问如何设置永久代内存大小，你可以用-XX:PermSize和-XX:MaxPermSize参数来进行设置，但是要记住，只有当出现OutOfMemoryError错误时你才需要去设置永久代内存。

GC 优化的过程

GC 优化的过程大致可分为以下步骤：

（1）监控 GC 状态

你需要监控 GC 从而检查系统中运行的 GC 的各种状态。

（2）分析 GC 日志

在检查 GC 状态后，你需要分析监控结构并决定是否需要进行 GC 优化。如果分析结果显示运行 GC 的时间只有 0.1-0.3 秒，那么就不需要把时间浪费在 GC 优化上，但如果运行 GC 的时间达到 1-3 秒，甚至大于 10 秒，那么 GC 优化将是很有必要的。

但是，如果你已经分配了大约 10GB 内存给 Java，并且这些内存无法省下，那么就无法进行 GC 优化了。在进行 GC 优化之前，你需要考虑为什么你需要分配这么大的内存空间，如果你分配了 1GB 或 2GB 大小的内存并且出现了OutOfMemoryError，那你就应该执行堆快照（heap dump）来消除导致异常的原因。

🔔 注意：

堆快照（heap dump）是一个用来检查 Java 内存中的对象和数据的内存文件。该文件可以通过执行 JDK 中的jmap命令来创建。在创建文件的过程中，所有 Java 程序都将暂停，因此，不要在系统执行过程中创建该文件。

你可以在互联网上搜索 heap dump 的详细说明。

（3）选择合适 GC 回收器

如果你决定要进行 GC 优化，那么你需要选择一个 GC 回收器，并且为它设置合理 JVM 参数。此时如果你有多个服务器，请如上文提到的那样，在每台机器上设置不同的 GC 参数并分析它们的区别。

（4）分析结果

在设置完 GC 参数后就可以开始收集数据，请在收集至少 24 小时后再进行结果分析。如果你足够幸运，你可能会找到系统的最佳 GC 参数。如若不然，你还需要分析输出日志并检查分配的内存，然后需要通过不断调整 GC 类型/内存大小来找到系统的最佳参数。

（5）应用优化配置

如果 GC 优化的结果令人满意，就可以将参数应用到所有服务器上，并停止 GC 优化。

在下面的章节中，你将会看到上述每一步所做的具体工作。

GC 日志

获取 GC 日志

获取 GC 日志有两种方式：

• 使用 jstat 命令动态查看
• 在容器中设置相关参数打印 GC 日志

jstat 命令查看 GC

jstat -gc 统计垃圾回收堆的行为：

1
2
3

jstat -gc 1262
 S0C    S1C     S0U     S1U   EC       EU        OC         OU        PC       PU         YGC    YGCT    FGC    FGCT     GCT
26112.0 24064.0 6562.5  0.0   564224.0 76274.5   434176.0   388518.3  524288.0 42724.7    320    6.417   1      0.398    6.815

也可以设置间隔固定时间来打印：

1

jstat -gc 1262 2000 20

这个命令意思就是每隔 2000ms 输出 1262 的 gc 情况，一共输出 20 次

打印 GC 的参数

通过 JVM 参数预先设置 GC 日志，通常有以下几种 JVM 参数设置：

1
2
3
4
5
6

-XX:+PrintGC 输出 GC 日志
-XX:+PrintGCDetails 输出 GC 的详细日志
-XX:+PrintGCTimeStamps 输出 GC 的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出 GC 的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行 GC 的前后打印出堆的信息
-verbose:gc -Xloggc:../logs/gc.log 日志文件的输出路径

如果是长时间的 GC 日志，我们很难通过文本形式去查看整体的 GC 性能。此时，我们可以通过GCView工具打开日志文件，图形化界面查看整体的 GC 性能。

【示例】Tomcat 设置示例

1
2
3
4
5
6

JAVA_OPTS="-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4
-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log
-Djava.awt.headless=true
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15"

• -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m
  Xms，即为 jvm 启动时得 JVM 初始堆大小,Xmx 为 jvm 的最大堆大小，xmn 为新生代的大小，permsize 为永久代的初始大小，MaxPermSize 为永久代的最大空间。
• -XX:SurvivorRatio=4
  SurvivorRatio 为新生代空间中的 Eden 区和救助空间 Survivor 区的大小比值，默认是 8，则两个 Survivor 区与一个 Eden 区的比值为 2:8,一个 Survivor 区占整个年轻代的 1/10。调小这个参数将增大 survivor 区，让对象尽量在 survitor 区呆长一点，减少进入年老代的对象。去掉救助空间的想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值（比如 65536)来做到。
• -verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log
  将虚拟机每次垃圾回收的信息写到日志文件中，文件名由 file 指定，文件格式是平文件，内容和-verbose:gc 输出内容相同。
• -Djava.awt.headless=true Headless 模式是系统的一种配置模式。在该模式下，系统缺少了显示设备、键盘或鼠标。
• -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
  设置 gc 日志的格式
• -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
  指定 rmi 调用时 gc 的时间间隔
• -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15 采用并发 gc 方式，经过 15 次 minor gc 后进入年老代

分析 GC 日志

Young GC 回收日志:

1

2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs]

Full GC 回收日志:

1

2016-07-05T10:43:18.160+0800: 25.462: [Full GC [PSYoungGen: 10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]

通过上面日志分析得出，PSYoungGen、ParOldGen、PSPermGen 属于 Parallel 收集器。其中 PSYoungGen 表示 gc 回收前后年轻代的内存变化；ParOldGen 表示 gc 回收前后老年代的内存变化；PSPermGen 表示 gc 回收前后永久区的内存变化。young gc 主要是针对年轻代进行内存回收比较频繁，耗时短；full gc 会对整个堆内存进行回城，耗时长，因此一般尽量减少 full gc 的次数

通过两张图非常明显看出 gc 日志构成：

YOUNG GC

FULL GC

CPU 过高

定位步骤：

（1）执行 top -c 命令，找到 cpu 最高的进程的 id

（2）jstack PID 导出 Java 应用程序的线程堆栈信息。

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

jstack 6795

"Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000]
        "CompilerThread0" daemon prio=10 tid=0x08143c58 nid=0x6 waiting on condition [0x00000000..0xfb5fd798]
        "Signal Dispatcher" daemon prio=10 tid=0x08142f08 nid=0x5 waiting on condition [0x00000000..0x00000000]
        "Finalizer" daemon prio=10 tid=0x08137ca0 nid=0x4 in Object.wait() [0xfbeed000..0xfbeeddb8]

        at java.lang.Object.wait(Native Method)

        - waiting on <0xef600848> (a java.lang.ref.ReferenceQueue$Lock)

        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)

        - locked <0xef600848> (a java.lang.ref.ReferenceQueue$Lock)

        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)

        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

        "Reference Handler" daemon prio=10 tid=0x081370f0 nid=0x3 in Object.wait() [0xfbf4a000..0xfbf4aa38]

        at java.lang.Object.wait(Native Method)

        - waiting on <0xef600758> (a java.lang.ref.Reference$Lock)

        at java.lang.Object.wait(Object.java:474)

        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)

        - locked <0xef600758> (a java.lang.ref.Reference$Lock)

        "VM Thread" prio=10 tid=0x08134878 nid=0x2 runnable

        "VM Periodic Task Thread" prio=10 tid=0x08147768 nid=0x8 waiting on condition

在打印的堆栈日志文件中，tid 和 nid 的含义：

1
2

nid : 对应的 Linux 操作系统下的 tid 线程号，也就是前面转化的 16 进制数字
tid: 这个应该是 jvm 的 jmm 内存规范中的唯一地址定位

在 CPU 过高的情况下，查找响应的线程，一般定位都是用 nid 来定位的。而如果发生死锁之类的问题，一般用 tid 来定位。

（3）定位 CPU 高的线程打印其 nid

查看线程下具体进程信息的命令如下：

top -H -p 6735

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

top - 14:20:09 up 611 days,  2:56,  1 user,  load average: 13.19, 7.76, 7.82
Threads: 6991 total,  17 running, 6974 sleeping,   0 stopped,   0 zombie
%Cpu(s): 90.4 us,  2.1 sy,  0.0 ni,  7.0 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
KiB Mem:  32783044 total, 32505008 used,   278036 free,   120304 buffers
KiB Swap:        0 total,        0 used,        0 free. 4497428 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 6800 root      20   0 27.299g 0.021t   7172 S 54.7 70.1 187:55.61 java
 6803 root      20   0 27.299g 0.021t   7172 S 54.4 70.1 187:52.59 java
 6798 root      20   0 27.299g 0.021t   7172 S 53.7 70.1 187:55.08 java
 6801 root      20   0 27.299g 0.021t   7172 S 53.7 70.1 187:55.25 java
 6797 root      20   0 27.299g 0.021t   7172 S 53.1 70.1 187:52.78 java
 6804 root      20   0 27.299g 0.021t   7172 S 53.1 70.1 187:55.76 java
 6802 root      20   0 27.299g 0.021t   7172 S 52.1 70.1 187:54.79 java
 6799 root      20   0 27.299g 0.021t   7172 S 51.8 70.1 187:53.36 java
 6807 root      20   0 27.299g 0.021t   7172 S 13.6 70.1  48:58.60 java
11014 root      20   0 27.299g 0.021t   7172 R  8.4 70.1   8:00.32 java
10642 root      20   0 27.299g 0.021t   7172 R  6.5 70.1   6:32.06 java
 6808 root      20   0 27.299g 0.021t   7172 S  6.1 70.1 159:08.40 java
11315 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   5:54.10 java
12545 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   6:55.48 java
23353 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   2:20.55 java
24868 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   2:12.46 java
 9146 root      20   0 27.299g 0.021t   7172 S  3.6 70.1   7:42.72 java

由此可以看出占用 CPU 较高的线程，但是这些还不高，无法直接定位到具体的类。nid 是 16 进制的，所以我们要获取线程的 16 进制 ID：

1

printf "%x\n" 6800

1

输出结果:45cd

然后根据输出结果到 jstack 打印的堆栈日志中查定位：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

"catalina-exec-5692" daemon prio=10 tid=0x00007f3b05013800 nid=0x45cd waiting on condition [0x00007f3ae08e3000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006a7800598> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
        at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
        at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)
        at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)

GC 配置

详细参数说明请参考官方文档：JavaHotSpot VM Options，这里仅列举常用参数。

堆大小设置

年轻代的设置很关键。

JVM 中最大堆大小有三方面限制：

1. 相关操作系统的数据模型（32-bt 还是 64-bit）限制；
2. 系统的可用虚拟内存限制；
3. 系统的可用物理内存限制。

1

整个堆大小 = 年轻代大小 + 年老代大小 + 持久代大小

• 持久代一般固定大小为 64m。使用 -XX:PermSize 设置。
• 官方推荐年轻代占整个堆的 3/8。使用 -Xmn 设置。

JVM 内存配置

GC 类型配置

垃圾回收器通用参数

JMX

开启 JMX 后，可以使用 jconsole 或 jvisualvm 进行监控 Java 程序的基本信息和运行情况。

1
2
3
4
5

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote.port=18888

-Djava.rmi.server.hostname 指定 Java 程序运行的服务器，-Dcom.sun.management.jmxremote.port 指定服务监听端口。

远程 DEBUG

如果开启 Java 应用的远程 Debug 功能，需要指定如下参数：

1
2
3
4

-Xdebug
-Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,address=28888,server=y,suspend=n

address 即为远程 debug 的监听端口。

HeapDump

1

-XX:-OmitStackTraceInFastThrow -XX:+HeapDumpOnOutOfMemoryError

辅助配置

参考资料

• 《深入理解 Java 虚拟机》
• 极客时间教程 - Java 性能调优实战
• 从表到里学习 JVM 实现
• JVM（4）：Jvm 调优-命令篇
• Java 系列笔记(4) - JVM 监控与调优
• Java 服务 GC 参数调优案例
• JVM 调优总结（5）：典型配置
• 如何合理的规划一次 jvm 性能调优
• jvm 系列(九):如何优化 Java GC“译”
• https://my.oschina.net/feichexia/blog/196575

分库分表基本原理

为何要分库分表

分库分表主要基于以下理由：

• 并发连接 - 单库超过每秒 2000 个并发时，而一个健康的单库最好保持在每秒 1000 个并发左右，不要太大。
• 磁盘容量 - 磁盘容量占满，会导致服务器不可用。
• SQL 性能 - 单表数据量过大，会导致 SQL 执行效率低下。一般，单表超过 1000 万条数据，就可以考虑分表了。

分库分表原理

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中以达到提升性能瓶颈以及可用性的效果。 数据分片的有效手段是对关系型数据库进行分库和分表。分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈。 除此之外，分库还能够用于有效的分散对数据库单点的访问量；分表虽然无法缓解数据库压力，但却能够提供尽量将分布式事务转化为本地事务的可能，一旦涉及到跨库的更新操作，分布式事务往往会使问题变得复杂。 使用多主多从的分片方式，可以有效的避免数据单点，从而提升数据架构的可用性。

通过分库和分表进行数据的拆分来使得各个表的数据量保持在阈值以下，以及对流量进行疏导应对高访问量，是应对高并发和海量数据系统的有效手段。 数据分片的拆分方式又分为垂直分片和水平分片。

垂直分片

垂直分片有两种拆分考量：业务拆分和访问频率拆分

（1）业务拆分

业务拆分的核心理念是专库专用。

在拆分之前，一个数据库由多个数据表构成，每个表对应着不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库中，从而将压力分散至不同的数据库。下图展示了根据业务需要，将用户表和订单表垂直分片到不同的数据库的方案。

垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

（2）访问频率拆分

访问频率拆分，是 把一个有很多字段的表给拆分成多个表，或者是多个库上去。一般来说，会 将较少的、访问频率较高的字段放到一个表中，然后 将较多的、访问频率较低的字段放到另外一个表中。因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。

一般来说，满足下面的条件就可以考虑扩容了：

• Mysql 单库超过 5000 万条记录，Oracle 单库超过 1 亿条记录，DB 压力就很大。
• 单库超过每秒 2000 个并发时，而一个健康的单库最好保持在每秒 1000 个并发左右，不要太大。

在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不同的库中，例如将原来的电商数据库垂直切分成商品数据库、用户数据库等。

水平分片

水平拆分 又称为 Sharding，它是将同一个表中的记录拆分到多个结构相同的表中。当 单表数据量太大 时，会极大影响 SQL 执行的性能 。分表是将原来一张表的数据分布到数据库集群的不同节点上，从而缓解单点的压力。

相对于垂直分片，水平分片不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。 例如：根据主键分片，偶数主键的记录放入 0 库（或表），奇数主键的记录放入 1 库（或表）。

水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是分库分表的标准解决方案。

一般来说，单表有 200 万条数据 的时候，性能就会相对差一些了，需要考虑分表了。但是，这也要视具体情况而定，可能是 100 万条，也可能是 500 万条，SQL 越复杂，就最好让单表行数越少。

读写分离的数据节点中的数据内容是一致的，而水平分片的每个数据节点的数据内容却并不相同。将水平分片和读写分离联合使用，能够更加有效的提升系统性能。

分库分表策略

分库分表策略主要有两种：

• 根据数值范围划分
• 根据 Hash 划分

数值范围路由

数值范围路由，就是根据 ID、时间范围 这类具有排序性的字段来进行划分。例如：用户 Id 为 1-9999 的记录分到第一个库，10000-20000 的分到第二个库，以此类推。

按这种策略划分出来的数据，具有数据连续性。

优点：数据迁移很简单。

缺点：容易产生热点问题，大量的流量都打在最新的数据上了。

Hash 路由

典型的 Hash 路由，如根据数值取模，当需要扩容时，一般以 2 的幂次方进行扩容（这样，扩容时迁移的数据量会小一些）。例如：用户 Id mod n，余数为 0 的记录放到第一个库，余数为 1 的放到第二个库，以此类推。

一般采用 预分区 的方式，提前根据 数据量 规划好 分区数，比如划分为 512 或 1024 张表，保证可支撑未来一段时间的 数据容量，再根据 负载情况 将 表 迁移到其他 数据库 中。扩容时通常采用 翻倍扩容，避免 数据映射 全部被 打乱，导致 全量迁移 的情况。

优点：数据离散分布，不存在热点问题。

缺点：数据迁移、扩容麻烦（之前的数据需要重新计算 hash 值重新分配到不同的库或表）。当 节点数量 变化时，如 扩容 或 收缩 节点，数据节点 映射关系 需要重新计算，会导致数据的 重新迁移。

路由表

这种策略，就是用一张独立的表记录路由信息。

优点：简单、灵活，尤其是在扩容、迁移时，只需要迁移指定的数据，然后修改路由表即可。

缺点：每次查询，必须先查路由表，增加了 IO 开销。并且，如果路由表本身太大，也会面临性能瓶颈，如果想对路由表再做分库分表，将出现死循环式的路由算法选择问题。

迁移和扩容

停机迁移/扩容（不推荐）

停机迁移/扩容是最暴力、最简单的迁移、扩容方案。

停机迁移/扩容流程

（0）预估停服时间，发布停服公告。

（1）停服，不允许数据访问。

（2）编写临时的数据导入程序，从老数据库中读取数据。

（3）将数据写入中间件。

（4）中间件根据分片规则，将数据分发到分库（分表）中。

（5）应用程序修改配置，重启。

停机迁移/扩容方案分析

优点：简单、没有数据一致性问题。

缺点：如果老的数据库数据量很大，则停机处理时间可能很久。比如老的数据库是已经分库分表的数据库群，数据量可能达到亿级，导入数据可能就要花费几小时。如果中间过程中出现问题，就容易引发重大事故。

点评：综上，这种方案代价太高，不可取。

双写迁移

双写迁移的改造方案如下：

• 支持双写新旧两个库，并且预留热切换开关，能通过开关控制三种写状态：只写旧库、只写新库和同步双写。
• 支持读新旧两个库，同样预留热切换开关，控制读旧库还是新库。

然后上线新版服务，这个时候服务仍然是只读写旧库，不读写新库。新版服务需要稳定运行至少一到二周的时间，期间除了验证新版服务的稳定性以外，还要验证新旧两个库中的数据是否是一致的。这个过程中，如果新版服务有问题，可以立即下线新版服务，回滚到旧版本的服务。

稳定一段时间之后，就可以开启服务的双写开关了。开启双写开关的同时，需要停掉同步程序。这里面有一个问题需要注意一下，就是这个双写的业务逻辑，一定是先写旧库，再写新库，并且以写旧库的结果为准。

旧库写成功，新库写失败，返回写成功，但这个时候要记录日志，后续我们会用到这个日志来验证新库是否还有问题。旧库写失败，直接返回失败，就不写新库了。这么做的原因是，不能让新库影响到现有业务的可用性和数据准确性。上面这个过程如果出现问题，可以关闭双写，回滚到只读写旧库的状态。

切换到双写之后，新库与旧库的数据可能会存在不一致的情况，原因有两个：一、停止同步程序和开启双写，这两个过程很难做到无缝衔接，二、双写的策略也不保证新旧库强一致，这时候我们需要上线一个对比和补偿的程序，这个程序对比旧库最近的数据变更，然后检查新库中的数据是否一致，如果不一致，还要进行补偿。

开启双写后，还需要至少稳定运行至少几周的时间，并且期间我们要不断地检查，确保不能有旧库写成功，新库写失败的情况出现。对比程序也没有发现新旧两个库的数据有不一致的情况，这个时候，我们就可以认为，新旧两个库的数据是一直保持同步的。接下来就可以用类似灰度发布的方式，把读请求一点儿一点儿地切到新库上。同样，期间如果出问题的话，可以再切回旧库。全部读请求都切换到新库上之后，这个时候其实读写请求就已经都切换到新库上了，实际的切换已经完成了，但还有后续的收尾步骤。

双写迁移流程

1. 修改应用程序配置，将数据同时写入老数据库和中间件。这就是所谓的双写，同时写俩库，老库和新库。

2. 编写临时程序，读取老数据库。

3. 将数据写入中间件。如果数据不存在，直接写入；如果数据存在，比较时间戳，只允许新数据覆盖老数据。

4. 导入数据后，有可能数据还是存在不一致，那么就对数据进行校验，比对新老库的每条数据。如果存在差异，针对差异数据，执行（3）。循环（3）、（4）步骤，直至数据完全一致。

5. 修改应用程序配置，将数据只写入中间件。

6. 中间件根据分片规则，将数据分发到分库（分表）中。

主从升级

生产环境的数据库，为了保证高可用，一般会采用主备架构。主库支持读写操作，从库支持读操作。

由于主备节点数据一致，所以将从库升级为主节点，并修改分片配置，将从节点作为分库之一，就实现了扩容。

升级从库的流程

（1）解除主从关系，从库升级为主库。

（2）应用程序，修改配置，读写通过中间件。

（3）分库分表中间，修改分片配置。将数据按照新的规则分发。

（4）编写临时程序，清理冗余数据。比如：原来是一个单库，数据量为 400 万。从节点升级为分库之一后，每个分库都有 400 万数据，其中 200 万是冗余数据。清理完后，进行数据校验。

（5）为每个分库添加新的从库，保证高可用。

升级从库方案分析

优点：不需要停机，无需数据迁移。

分库分表的问题

分布式 ID 问题

一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的 ID 无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得 ID，以便进行 SQL 路由。

分布式 ID 的解决方案详见：分布式 ID

分布式事务问题

跨库事务也是分布式的数据库集群要面对的棘手事情。 合理采用分表，可以在降低单表数据量的情况下，尽量使用本地事务，善于使用同库不同表可有效避免分布式事务带来的麻烦。在不能避免跨库事务的场景，有些业务仍然需要保持事务的一致性。 而基于 XA 的分布式事务由于在并发度高的场景中性能无法满足需要，并未被互联网巨头大规模使用，他们大多采用最终一致性的柔性事务代替强一致事务。

分布式事务的解决方案详见：分布式事务

跨节点 Join 和聚合

分库分表后，无法直接跨节点 join 、count、order by、group by 以及聚合。

针对这类问题，普遍做法是二次查询。

在第一次查询时，获取各个节点上的结果。

在程序中将这些结果进行合并、筛选。

跨分片的排序分页

一般来讲，分页时需要按照指定字段进行排序。当排序字段就是分片字段的时候，我们通过分片规则可以比较容易定位到指定的分片，而当排序字段非分片字段的时候，情况就会变得比较复杂了。为了最终结果的准确性，我们需要在不同的分片节点中将数据进行排序并返回，并将不同分片返回的结果集进行汇总和再次排序，最后再返回给用户。如下图所示：

上面图中所描述的只是最简单的一种情况（取第一页数据），看起来对性能的影响并不大。但是，如果想取出第 10 页数据，情况又将变得复杂很多，如下图所示：

有些读者可能并不太理解，为什么不能像获取第一页数据那样简单处理（排序取出前 10 条再合并、排序）。其实并不难理解，因为各分片节点中的数据可能是随机的，为了排序的准确性，必须把所有分片节点的前 N 页数据都排序好后做合并，最后再进行整体的排序。很显然，这样的操作是比较消耗资源的，用户越往后翻页，系统性能将会越差。

那如何解决分库情况下的分页问题呢？有以下几种办法：

如果是在前台应用提供分页，则限定用户只能看前面 n 页，这个限制在业务上也是合理的，一般看后面的分页意义不大（如果一定要看，可以要求用户缩小范围重新查询）。

如果是后台批处理任务要求分批获取数据，则可以加大 page size，比如每次获取 5000 条记录，有效减少分页数（当然离线访问一般走备库，避免冲击主库）。

分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台。

中间件

国内常见分库分表中间件：

• Cobar - 阿里 b2b 团队开发和开源的，属于 proxy 层方案，就是介于应用服务器和数据库服务器之间。应用程序通过 JDBC 驱动访问 cobar 集群，cobar 根据 SQL 和分库规则对 SQL 做分解，然后分发到 MySQL 集群不同的数据库实例上执行。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。
• TDDL - 淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。
• Atlas - 360 开源的，属于 proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。
• sharding-jdbc - 当当开源的，属于 client 层方案。确实之前用的还比较多一些，因为 SQL 语法支持也比较多，没有太多限制，而且目前推出到了 2.0 版本，支持分库分表、读写分离、分布式 id 生成、柔性事务（最大努力送达型事务、TCC 事务）。而且确实之前使用的公司会比较多一些（这个在官网有登记使用的公司，可以看到从 2017 年一直到现在，是有不少公司在用的），目前社区也还一直在开发和维护，还算是比较活跃，个人认为算是一个现在也可以选择的方案。
• Mycat - 基于 cobar 改造的，属于 proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 sharding jdbc 来说，年轻一些，经历的锤炼少一些。

技术选型建议：

建议使用的是 sharding-jdbc 和 mycat。

• sharding-jdbc 这种 client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖。其本质上通过配置多数据源，然后根据设定的分库分表策略，计算路由，将请求发送到计算得到的节点上。
• Mycat 这种 proxy 层方案的缺点在于需要部署，自己运维一套中间件，运维成本高，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。

通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用 sharding-jdbc，client 层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；但是中大型公司最好还是选用 mycat 这类 proxy 层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护 mycat，然后大量项目直接透明使用即可。

参考资料

• 后端存储实战课
• ShardingSphere 官方文档
• “分库分表” ？选型和流程要慎重，否则会失控
• 分库分表需要考虑的问题及方案
• 一次难得的分库分表实践
• 分库分表平滑扩容

Systemd 应用

搬运自：Systemd 入门教程：命令篇、Systemd 入门教程：实战篇

Systemd 是 Linux 系统工具，用来启动守护进程，已成为大多数发行版的标准配置。

本文介绍它的基本用法，分为上下两篇。今天介绍它的主要命令，下一篇介绍如何用于实战。

由来

历史上，Linux 的启动一直采用init进程。

下面的命令用来启动服务。

1
2
3

$ sudo /etc/init.d/apache2 start
# 或者
$ service apache2 start

这种方法有两个缺点。

一是启动时间长。init进程是串行启动，只有前一个进程启动完，才会启动下一个进程。

二是启动脚本复杂。init进程只是执行启动脚本，不管其他事情。脚本需要自己处理各种
情况，这往往使得脚本变得很长。

Systemd 概述

Systemd 就是为了解决这些问题而诞生的。它的设计目标是，为系统的启动和管理提供一套
完整的解决方案。

根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就
是它要守护整个系统。

使用了 Systemd，就不需要再用init了。Systemd 取代了initd，成为系统的第一个进
程（PID 等于 1），其他进程都是它的子进程。

1

$ systemctl --version

上面的命令查看 Systemd 的版本。

Systemd 的优点是功能强大，使用方便，缺点是体系庞大，非常复杂。事实上，现在还有很
多人反对使用 Systemd，理由就是它过于复杂，与操作系统的其他部分强耦合，违反”keep
simple, keep stupid”
的Unix 哲学。

（上图为 Systemd 架构图）

系统管理

Systemd 并不是一个命令，而是一组命令，涉及到系统管理的方方面面。

systemctl

systemctl是 Systemd 的主命令，用于管理系统。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 重启系统
$ sudo systemctl reboot

# 关闭系统，切断电源
$ sudo systemctl poweroff

# CPU停止工作
$ sudo systemctl halt

# 暂停系统
$ sudo systemctl suspend

# 让系统进入冬眠状态
$ sudo systemctl hibernate

# 让系统进入交互式休眠状态
$ sudo systemctl hybrid-sleep

# 启动进入救援状态（单用户状态）
$ sudo systemctl rescue

systemd-analyze

systemd-analyze命令用于查看启动耗时。

1
2
3
4
5
6
7
8
9
10
11

# 查看启动耗时
$ systemd-analyze

# 查看每个服务的启动耗时
$ systemd-analyze blame

# 显示瀑布状的启动过程流
$ systemd-analyze critical-chain

# 显示指定服务的启动流
$ systemd-analyze critical-chain atd.service

hostnamectl

hostnamectl命令用于查看当前主机的信息。

1
2
3
4
5

# 显示当前主机的信息
$ hostnamectl

# 设置主机名。
$ sudo hostnamectl set-hostname rhel7

localectl

localectl命令用于查看本地化设置。

1
2
3
4
5
6

# 查看本地化设置
$ localectl

# 设置本地化参数。
$ sudo localectl set-locale LANG=en_GB.utf8
$ sudo localectl set-keymap en_GB

timedatectl

timedatectl命令用于查看当前时区设置。

1
2
3
4
5
6
7
8
9
10

# 查看当前时区设置
$ timedatectl

# 显示所有可用的时区
$ timedatectl list-timezones

# 设置当前时区
$ sudo timedatectl set-timezone America/New_York
$ sudo timedatectl set-time YYYY-MM-DD
$ sudo timedatectl set-time HH:MM:SS

loginctl

loginctl命令用于查看当前登录的用户。

1
2
3
4
5
6
7
8

# 列出当前session
$ loginctl list-sessions

# 列出当前登录用户
$ loginctl list-users

# 列出显示指定用户的信息
$ loginctl show-user ruanyf

Unit

含义

Systemd 可以管理所有系统资源。不同的资源统称为 Unit（单位）。

Unit 一共分成 12 种。

• Service unit：系统服务
• Target unit：多个 Unit 构成的一个组
• Device Unit：硬件设备
• Mount Unit：文件系统的挂载点
• Automount Unit：自动挂载点
• Path Unit：文件或路径
• Scope Unit：不是由 Systemd 启动的外部进程
• Slice Unit：进程组
• Snapshot Unit：Systemd 快照，可以切回某个快照
• Socket Unit：进程间通信的 socket
• Swap Unit：swap 文件
• Timer Unit：定时器

systemctl list-units命令可以查看当前系统的所有 Unit 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 列出正在运行的 Unit
$ systemctl list-units

# 列出所有Unit，包括没有找到配置文件的或者启动失败的
$ systemctl list-units --all

# 列出所有没有运行的 Unit
$ systemctl list-units --all --state=inactive

# 列出所有加载失败的 Unit
$ systemctl list-units --failed

# 列出所有正在运行的、类型为 service 的 Unit
$ systemctl list-units --type=service

Unit 的状态

systemctl status命令用于查看系统状态和单个 Unit 的状态。

1
2
3
4
5
6
7
8

# 显示系统状态
$ systemctl status

# 显示单个 Unit 的状态
$ sysystemctl status bluetooth.service

# 显示远程主机的某个 Unit 的状态
$ systemctl -H root@rhel7.example.com status httpd.service

除了status命令，systemctl还提供了三个查询状态的简单方法，主要供脚本内部的判
断语句使用。

1
2
3
4
5
6
7
8

# 显示某个 Unit 是否正在运行
$ systemctl is-active application.service

# 显示某个 Unit 是否处于启动失败状态
$ systemctl is-failed application.service

# 显示某个 Unit 服务是否建立了启动链接
$ systemctl is-enabled application.service

Unit 管理

对于用户来说，最常用的是下面这些命令，用于启动和停止 Unit（主要是 service）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 立即启动一个服务
$ sudo systemctl start apache.service

# 立即停止一个服务
$ sudo systemctl stop apache.service

# 重启一个服务
$ sudo systemctl restart apache.service

# 杀死一个服务的所有子进程
$ sudo systemctl kill apache.service

# 重新加载一个服务的配置文件
$ sudo systemctl reload apache.service

# 重载所有修改过的配置文件
$ sudo systemctl daemon-reload

# 显示某个 Unit 的所有底层参数
$ systemctl show httpd.service

# 显示某个 Unit 的指定属性的值
$ systemctl show -p CPUShares httpd.service

# 设置某个 Unit 的指定属性
$ sudo systemctl set-property httpd.service CPUShares=500

依赖关系

Unit 之间存在依赖关系：A 依赖于 B，就意味着 Systemd 在启动 A 的时候，同时会去启
动 B。

systemctl list-dependencies命令列出一个 Unit 的所有依赖。

1

$ systemctl list-dependencies nginx.service

上面命令的输出结果之中，有些依赖是 Target 类型（详见下文），默认不会展开显示。如
果要展开 Target，就需要使用--all参数。

1

$ systemctl list-dependencies --all nginx.service

Unit 的配置文件

概述

每一个 Unit 都有一个配置文件，告诉 Systemd 怎么启动这个 Unit 。

Systemd 默认从目录/etc/systemd/system/读取配置文件。但是，里面存放的大部分文件
都是符号链接，指向目录/usr/lib/systemd/system/，真正的配置文件存放在那个目录。

systemctl enable命令用于在上面两个目录之间，建立符号链接关系。

1
2
3

$ sudo systemctl enable clamd@scan.service
# 等同于
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'

如果配置文件里面设置了开机启动，systemctl enable命令相当于激活开机启动。

与之对应的，systemctl disable命令用于在两个目录之间，撤销符号链接关系，相当于
撤销开机启动。

1

$ sudo systemctl disable clamd@scan.service

配置文件的后缀名，就是该 Unit 的种类，比如sshd.socket。如果省略，Systemd 默认
后缀名为.service，所以sshd会被理解成sshd.service。

配置文件的状态

systemctl list-unit-files命令用于列出所有配置文件。

1
2
3
4
5

# 列出所有配置文件
$ systemctl list-unit-files

# 列出指定类型的配置文件
$ systemctl list-unit-files --type=service

这个命令会输出一个列表。

1
2
3
4
5
6

$ systemctl list-unit-files

UNIT FILE              STATE
chronyd.service        enabled
clamd@.service         static
clamd@scan.service     disabled

这个列表显示每个配置文件的状态，一共有四种。

• enabled：已建立启动链接
• disabled：没建立启动链接
• static：该配置文件没有[Install]部分（无法执行），只能作为其他配置文件的依赖
• masked：该配置文件被禁止建立启动链接

注意，从配置文件的状态无法看出，该 Unit 是否正在运行。这必须执行前面提到
的systemctl status命令。

1

$ systemctl status bluetooth.service

一旦修改配置文件，就要让 SystemD 重新加载配置文件，然后重新启动，否则修改不会生
效。

1
2

$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service

配置文件的格式

配置文件就是普通的文本文件，可以用文本编辑器打开。

systemctl cat命令可以查看配置文件的内容。

1
2
3
4
5
6
7
8
9
10
11

$ systemctl cat atd.service

[Unit]
Description=ATD daemon

[Service]
Type=forking
ExecStart=/usr/bin/atd

[Install]
WantedBy=multi-user.target

从上面的输出可以看到，配置文件分成几个区块。每个区块的第一行，是用方括号表示的区
别名，比如[Unit]。注意，配置文件的区块名和字段名，都是大小写敏感的。

每个区块内部是一些等号连接的键值对。

1
2
3
4
5

[Section]
Directive1=value
Directive2=value

. . .

注意，键值对的等号两侧不能有空格。

配置文件的区块

[Unit]区块通常是配置文件的第一个区块，用来定义 Unit 的元数据，以及配置与其他
Unit 的关系。它的主要字段如下。

• Description：简短描述
• Documentation：文档地址
• Requires：当前 Unit 依赖的其他 Unit，如果它们没有运行，当前 Unit 会启动失败
• Wants：与当前 Unit 配合的其他 Unit，如果它们没有运行，当前 Unit 不会启动失败
• BindsTo：与Requires类似，它指定的 Unit 如果退出，会导致当前 Unit 停止运行
• Before：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之后启动
• After：如果该字段指定的 Unit 也要启动，那么必须在当前 Unit 之前启动
• Conflicts：这里指定的 Unit 不能与当前 Unit 同时运行
• Condition...：当前 Unit 运行必须满足的条件，否则不会运行
• Assert...：当前 Unit 运行必须满足的条件，否则会报启动失败

[Install]通常是配置文件的最后一个区块，用来定义如何启动，以及是否开机启动。它
的主要字段如下。

• WantedBy：它的值是一个或多个 Target，当前 Unit 激活时（enable）符号链接会放
  入/etc/systemd/system目录下面以 Target 名 + .wants后缀构成的子目录中
• RequiredBy：它的值是一个或多个 Target，当前 Unit 激活时，符号链接会放
  入/etc/systemd/system目录下面以 Target 名 + .required后缀构成的子目录中
• Alias：当前 Unit 可用于启动的别名
• Also：当前 Unit 激活（enable）时，会被同时激活的其他 Unit

[Service]区块用来 Service 的配置，只有 Service 类型的 Unit 才有这个区块。它的
主要字段如下。

• Type：定义启动时的进程行为。它有以下几种值。
• Type=simple：默认值，执行ExecStart指定的命令，启动主进程
• Type=forking：以 fork 方式从父进程创建子进程，创建后父进程会立即退出
• Type=oneshot：一次性进程，Systemd 会等当前服务退出，再继续往下执行
• Type=dbus：当前服务通过 D-Bus 启动
• Type=notify：当前服务启动完毕，会通知Systemd，再继续往下执行
• Type=idle：若有其他任务执行完毕，当前服务才会运行
• ExecStart：启动当前服务的命令
• ExecStartPre：启动当前服务之前执行的命令
• ExecStartPost：启动当前服务之后执行的命令
• ExecReload：重启当前服务时执行的命令
• ExecStop：停止当前服务时执行的命令
• ExecStopPost：停止当其服务之后执行的命令
• RestartSec：自动重启当前服务间隔的秒数
• Restart：定义何种情况 Systemd 会自动重启当前服务，可能的值包括always（总是
  重启）、on-success、on-failure、on-abnormal、on-abort、on-watchdog
• TimeoutSec：定义 Systemd 停止当前服务之前等待的秒数
• Environment：指定环境变量

Unit 配置文件的完整字段清单，请参
考官方文档。

Target

启动计算机的时候，需要启动大量的 Unit。如果每一次启动，都要一一写明本次启动需要
哪些 Unit，显然非常不方便。Systemd 的解决方案就是 Target。

简单说，Target 就是一个 Unit 组，包含许多相关的 Unit 。启动某个 Target 的时候
，Systemd 就会启动里面所有的 Unit。从这个意义上说，Target 这个概念类似于”状态点
“，启动某个 Target 就好比启动到某种状态。

传统的init启动模式里面，有 RunLevel 的概念，跟 Target 的作用很类似。不同的是
，RunLevel 是互斥的，不可能多个 RunLevel 同时启动，但是多个 Target 可以同时启动
。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 查看当前系统的所有 Target
$ systemctl list-unit-files --type=target

# 查看一个 Target 包含的所有 Unit
$ systemctl list-dependencies multi-user.target

# 查看启动时的默认 Target
$ systemctl get-default

# 设置启动时的默认 Target
$ sudo systemctl set-default multi-user.target

# 切换 Target 时，默认不关闭前一个 Target 启动的进程，
# systemctl isolate 命令改变这种行为，
# 关闭前一个 Target 里面所有不属于后一个 Target 的进程
$ sudo systemctl isolate multi-user.target

Target 与 传统 RunLevel 的对应关系如下。

1
2
3
4
5
6
7
8
9

Traditional runlevel      New target name     Symbolically linked to...

Runlevel 0           |    runlevel0.target -> poweroff.target
Runlevel 1           |    runlevel1.target -> rescue.target
Runlevel 2           |    runlevel2.target -> multi-user.target
Runlevel 3           |    runlevel3.target -> multi-user.target
Runlevel 4           |    runlevel4.target -> multi-user.target
Runlevel 5           |    runlevel5.target -> graphical.target
Runlevel 6           |    runlevel6.target -> reboot.target

它与init进程的主要差别如下。

（1）默认的 RunLevel（在/etc/inittab文件设置）现在被默认的 Target 取代，
位置是/etc/systemd/system/default.target，通常符号链接到graphical.target（
图形界面）或者multi-user.target（多用户命令行）。

（2）启动脚本的位置，以前是/etc/init.d目录，符号链接到不同的 RunLevel 目
录 （比如/etc/rc3.d、/etc/rc5.d等），现在则存放
在/lib/systemd/system和/etc/systemd/system目录。

（3）配置文件的位置，以前init进程的配置文件是/etc/inittab，各种服务的
配置文件存放在/etc/sysconfig目录。现在的配置文件主要存放在/lib/systemd目录
，在/etc/systemd目录里面的修改可以覆盖原始设置。

日志管理

Systemd 统一管理所有 Unit 的启动日志。带来的好处就是，可以只用journalctl一个命
令，查看所有日志（内核日志和应用日志）。日志的配置文件
是/etc/systemd/journald.conf。

journalctl功能强大，用法非常多。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

# 查看所有日志（默认情况下 ，只保存本次启动的日志）
$ sudo journalctl

# 查看内核日志（不显示应用日志）
$ sudo journalctl -k

# 查看系统本次启动的日志
$ sudo journalctl -b
$ sudo journalctl -b -0

# 查看上一次启动的日志（需更改设置）
$ sudo journalctl -b -1

# 查看指定时间的日志
$ sudo journalctl --since="2012-10-30 18:17:16"
$ sudo journalctl --since "20 min ago"
$ sudo journalctl --since yesterday
$ sudo journalctl --since "2015-01-10" --until "2015-01-11 03:00"
$ sudo journalctl --since 09:00 --until "1 hour ago"

# 显示尾部的最新10行日志
$ sudo journalctl -n

# 显示尾部指定行数的日志
$ sudo journalctl -n 20

# 实时滚动显示最新日志
$ sudo journalctl -f

# 查看指定服务的日志
$ sudo journalctl /usr/lib/systemd/systemd

# 查看指定进程的日志
$ sudo journalctl _PID=1

# 查看某个路径的脚本的日志
$ sudo journalctl /usr/bin/bash

# 查看指定用户的日志
$ sudo journalctl _UID=33 --since today

# 查看某个 Unit 的日志
$ sudo journalctl -u nginx.service
$ sudo journalctl -u nginx.service --since today

# 实时滚动显示某个 Unit 的最新日志
$ sudo journalctl -u nginx.service -f

# 合并显示多个 Unit 的日志
$ journalctl -u nginx.service -u php-fpm.service --since today

# 查看指定优先级（及其以上级别）的日志，共有8级
# 0: emerg
# 1: alert
# 2: crit
# 3: err
# 4: warning
# 5: notice
# 6: info
# 7: debug
$ sudo journalctl -p err -b

# 日志默认分页输出，--no-pager 改为正常的标准输出
$ sudo journalctl --no-pager

# 以 JSON 格式（单行）输出
$ sudo journalctl -b -u nginx.service -o json

# 以 JSON 格式（多行）输出，可读性更好
$ sudo journalctl -b -u nginx.serviceqq
 -o json-pretty

# 显示日志占据的硬盘空间
$ sudo journalctl --disk-usage

# 指定日志文件占据的最大空间
$ sudo journalctl --vacuum-size=1G

# 指定日志文件保存多久
$ sudo journalctl --vacuum-time=1years

实战

开机启动

对于那些支持 Systemd 的软件，安装的时候，会自动在/usr/lib/systemd/system目录添
加一个配置文件。

如果你想让该软件开机启动，就执行下面的命令（以httpd.service为例）。

1

$ sudo systemctl enable httpd

上面的命令相当于在/etc/systemd/system目录添加一个符号链接，指
向/usr/lib/systemd/system里面的httpd.service文件。

这是因为开机时，Systemd只执行/etc/systemd/system目录里面的配置文件。这也意味
着，如果把修改后的配置文件放在该目录，就可以达到覆盖原始配置的效果。

启动服务

设置开机启动以后，软件并不会立即启动，必须等到下一次开机。如果想现在就运行该软件
，那么要执行systemctl start命令。

1

$ sudo systemctl start httpd

执行上面的命令以后，有可能启动失败，因此要用systemctl status命令查看一下该服务
的状态。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$ sudo systemctl status httpd

httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
Active: active (running) since 金 2014-12-05 12:18:22 JST; 7min ago
Main PID: 4349 (httpd)
Status: "Total requests: 1; Current requests/sec: 0; Current traffic:   0 B/sec"
CGroup: /system.slice/httpd.service
        ├─4349 /usr/sbin/httpd -DFOREGROUND
        ├─4350 /usr/sbin/httpd -DFOREGROUND
        ├─4351 /usr/sbin/httpd -DFOREGROUND
        ├─4352 /usr/sbin/httpd -DFOREGROUND
        ├─4353 /usr/sbin/httpd -DFOREGROUND
        └─4354 /usr/sbin/httpd -DFOREGROUND

12月 05 12:18:22 localhost.localdomain systemd[1]: Starting The Apache HTTP Server...
12月 05 12:18:22 localhost.localdomain systemd[1]: Started The Apache HTTP Server.
12月 05 12:22:40 localhost.localdomain systemd[1]: Started The Apache HTTP Server.

上面的输出结果含义如下。

• Loaded行：配置文件的位置，是否设为开机启动
• Active行：表示正在运行
• Main PID行：主进程 ID
• Status行：由应用本身（这里是 httpd ）提供的软件当前状态
• CGroup块：应用的所有子进程
• 日志块：应用的日志

停止服务

终止正在运行的服务，需要执行systemctl stop命令。

1

$ sudo systemctl stop httpd.service

有时候，该命令可能没有响应，服务停不下来。这时候就不得不”杀进程”了，向正在运行的
进程发出kill信号。

1

$ sudo systemctl kill httpd.service

此外，重启服务要执行systemctl restart命令。

1

$ sudo systemctl restart httpd.service

读懂配置文件

一个服务怎么启动，完全由它的配置文件决定。下面就来看，配置文件有些什么内容。

前面说过，配置文件主要放在/usr/lib/systemd/system目录，也可能
在/etc/systemd/system目录。找到配置文件以后，使用文本编辑器打开即可。

systemctl cat命令可以用来查看配置文件，下面以sshd.service文件为例，它的作用
是启动一个 SSH 服务器，供其他用户以 SSH 方式登录。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

$ systemctl cat sshd.service

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.service
Wants=sshd-keygen.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
Type=simple
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

可以看到，配置文件分成几个区块，每个区块包含若干条键值对。

下面依次解释每个区块的内容。

[Unit] 区块：启动顺序与依赖关系。

Unit区块的Description字段给出当前服务的简单描述，Documentation字段给出文档
位置。

接下来的设置是启动顺序和依赖关系，这个比较重要。

After字段：表示如果network.target或sshd-keygen.service需要启动，那
么sshd.service应该在它们之后启动。

相应地，还有一个Before字段，定义sshd.service应该在哪些服务之前启动。

注意，After和Before字段只涉及启动顺序，不涉及依赖关系。

举例来说，某 Web 应用需要 postgresql 数据库储存数据。在配置文件中，它只定义要在
postgresql 之后启动，而没有定义依赖 postgresql 。上线后，由于某种原因
，postgresql 需要重新启动，在停止服务期间，该 Web 应用就会无法建立数据库连接。

设置依赖关系，需要使用Wants字段和Requires字段。

Wants字段：表示sshd.service与sshd-keygen.service之间存在”弱依赖”关系，即
如果”sshd-keygen.service”启动失败或停止运行，不影响sshd.service继续执行。

Requires字段则表示”强依赖”关系，即如果该服务启动失败或异常退出，那
么sshd.service也必须退出。

注意，Wants字段与Requires字段只涉及依赖关系，与启动顺序无关，默认情况下是同
时启动的。

[Service] 区块：启动行为

Service区块定义如何启动当前服务。

启动命令

许多软件都有自己的环境参数文件，该文件可以用EnvironmentFile字段读取。

EnvironmentFile字段：指定当前服务的环境参数文件。该文件内部的key=value键值
对，可以用$key的形式，在当前配置文件中获取。

上面的例子中，sshd 的环境参数文件是/etc/sysconfig/sshd。

配置文件里面最重要的字段是ExecStart。

ExecStart字段：定义启动进程时执行的命令。

上面的例子中，启动sshd，执行的命令是/usr/sbin/sshd -D $OPTIONS，其中的变
量$OPTIONS就来自EnvironmentFile字段指定的环境参数文件。

与之作用相似的，还有如下这些字段。

• ExecReload字段：重启服务时执行的命令
• ExecStop字段：停止服务时执行的命令
• ExecStartPre字段：启动服务之前执行的命令
• ExecStartPost字段：启动服务之后执行的命令
• ExecStopPost字段：停止服务之后执行的命令

请看下面的例子。

1
2
3
4
5
6

[Service]
ExecStart=/bin/echo execstart1
ExecStart=
ExecStart=/bin/echo execstart2
ExecStartPost=/bin/echo post1
ExecStartPost=/bin/echo post2

上面这个配置文件，第二行ExecStart设为空值，等于取消了第一行的设置，运行结果如
下。

1
2
3

execstart2
post1
post2

所有的启动设置之前，都可以加上一个连词号（-），表示”抑制错误”，即发生错误的时
候，不影响其他命令的执行。比如，EnvironmentFile=-/etc/sysconfig/sshd（注意等号
后面的那个连词号），就表示即使/etc/sysconfig/sshd文件不存在，也不会抛出错误。

启动类型

Type字段定义启动类型。它可以设置的值如下。

• simple（默认值）：ExecStart字段启动的进程为主进程
• forking：ExecStart字段将以fork()方式启动，此时父进程将会退出，子进程将成
  为主进程
• oneshot：类似于simple，但只执行一次，Systemd 会等它执行完，才启动其他服务
• dbus：类似于simple，但会等待 D-Bus 信号后启动
• notify：类似于simple，启动结束后会发出通知信号，然后 Systemd 再启动其他服
  务
• idle：类似于simple，但是要等到其他任务都执行完，才会启动该服务。一种使用场
  合是为让该服务的输出，不与其他服务的输出相混合

下面是一个oneshot的例子，笔记本电脑启动时，要把触摸板关掉，配置文件可以这样写
。

1
2
3
4
5
6
7
8
9

[Unit]
Description=Switch-off Touchpad

[Service]
Type=oneshot
ExecStart=/usr/bin/touchpad-off

[Install]
WantedBy=multi-user.target

上面的配置文件，启动类型设为oneshot，就表明这个服务只要运行一次就够了，不需要
长期运行。

如果关闭以后，将来某个时候还想打开，配置文件修改如下。

1
2
3
4
5
6
7
8
9
10
11

[Unit]
Description=Switch-off Touchpad

[Service]
Type=oneshot
ExecStart=/usr/bin/touchpad-off start
ExecStop=/usr/bin/touchpad-off stop
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

上面配置文件中，RemainAfterExit字段设为yes，表示进程退出以后，服务仍然保持执
行。这样的话，一旦使用systemctl stop命令停止服务，ExecStop指定的命令就会执行
，从而重新开启触摸板。

重启行为

Service区块有一些字段，定义了重启行为。

KillMode字段：定义 Systemd 如何停止 sshd 服务。

上面这个例子中，将KillMode设为process，表示只停止主进程，不停止任何 sshd 子
进程，即子进程打开的 SSH session 仍然保持连接。这个设置不太常见，但对 sshd 很重
要，否则你停止服务的时候，会连自己打开的 SSH session 一起杀掉。

KillMode字段可以设置的值如下。

• control-group（默认值）：当前控制组里面的所有子进程，都会被杀掉
• process：只杀主进程
• mixed：主进程将收到 SIGTERM 信号，子进程收到 SIGKILL 信号
• none：没有进程会被杀掉，只是执行服务的 stop 命令。

接下来是Restart字段。

Restart字段：定义了 sshd 退出后，Systemd 的重启方式。

上面的例子中，Restart设为on-failure，表示任何意外的失败，就将重启 sshd。如果
sshd 正常停止（比如执行systemctl stop命令），它就不会重启。

Restart字段可以设置的值如下。

• no（默认值）：退出后不会重启
• on-success：只有正常退出时（退出状态码为 0），才会重启
• on-failure：非正常退出时（退出状态码非 0），包括被信号终止和超时，才会重启
• on-abnormal：只有被信号终止和超时，才会重启
• on-abort：只有在收到没有捕捉到的信号终止时，才会重启
• on-watchdog：超时退出，才会重启
• always：不管是什么退出原因，总是重启

对于守护进程，推荐设为on-failure。对于那些允许发生错误退出的服务，可以设
为on-abnormal。

最后是RestartSec字段。

RestartSec字段：表示 Systemd 重启服务之前，需要等待的秒数。上面的例子设为等
待 42 秒。

[Install] 区块

Install区块，定义如何安装这个配置文件，即怎样做到开机启动。

WantedBy字段：表示该服务所在的 Target。

Target的含义是服务组，表示一组服务。WantedBy=multi-user.target指的是，sshd
所在的 Target 是multi-user.target。

这个设置非常重要，因为执行systemctl enable sshd.service命令时
，sshd.service的一个符号链接，就会放在/etc/systemd/system目录下面
的multi-user.target.wants子目录之中。

Systemd 有默认的启动 Target。

1
2

$ systemctl get-default
multi-user.target

上面的结果表示，默认的启动 Target 是multi-user.target。在这个组里的所有服务，
都将开机启动。这就是为什么systemctl enable命令能设置开机启动的原因。

使用 Target 的时候，systemctl list-dependencies命令和systemctl isolate命令也
很有用。

1
2
3
4
5
6

# 查看 multi-user.target 包含的所有服务
$ systemctl list-dependencies multi-user.target

# 切换到另一个 target
# shutdown.target 就是关机状态
$ sudo systemctl isolate shutdown.target

一般来说，常用的 Target 有两个：一个是multi-user.target，表示多用户命令行状态
；另一个是graphical.target，表示图形用户状态，它依赖于multi-user.target。官
方文档有一张非常清晰的
Target 依赖关系图。

Target 的配置文件

Target 也有自己的配置文件。

1
2
3
4
5
6
7
8
9

$ systemctl cat multi-user.target

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

注意，Target 配置文件里面没有启动命令。

上面输出结果中，主要字段含义如下。

• Requires字段：要求basic.target一起运行。
• Conflicts字段：冲突字段。如果rescue.service或rescue.target正在运行
  ，multi-user.target就不能运行，反之亦然。
• After：表示multi-user.target在basic.target 、 rescue.service、
  rescue.target之后启动，如果它们有启动的话。
• AllowIsolate：允许使用systemctl isolate命令切换到multi-user.target。

修改配置文件后重启

修改配置文件以后，需要重新加载配置文件，然后重新启动相关服务。

1
2
3
4
5

# 重新加载配置文件
$ sudo systemctl daemon-reload

# 重启相关服务
$ sudo systemctl restart foobar

参考资料

• Systemd 入门教程：命令篇
• Systemd 入门教程：实战篇

Spring 资源管理

Version 6.0.3

Resource 接口

相对标准 URL 访问机制，Spring 的 org.springframework.core.io.Resource 接口抽象了对底层资源的访问接口，提供了一套更好的访问方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

public interface Resource extends InputStreamSource {

    boolean exists();

    boolean isReadable();

    boolean isOpen();

    boolean isFile();

    URL getURL() throws IOException;

    URI getURI() throws IOException;

    File getFile() throws IOException;

    ReadableByteChannel readableChannel() throws IOException;

    long contentLength() throws IOException;

    long lastModified() throws IOException;

    Resource createRelative(String relativePath) throws IOException;

    String getFilename();

    String getDescription();
}

正如 Resource 接口的定义所示，它扩展了 InputStreamSource 接口。Resource 最核心的方法如下：

• getInputStream() - 定位并且打开当前资源，返回当前资源的 InputStream。每次调用都会返回一个新的 InputStream。调用者需要负责关闭流。
• exists() - 判断当前资源是否真的存在。
• isOpen() - 判断当前资源是否是一个已打开的 InputStream。如果为 true，则 InputStream 不能被多次读取，必须只读取一次然后关闭以避免资源泄漏。对所有常用资源实现返回 false，InputStreamResource 除外。
• getDescription() - 返回当前资源的描述，当处理资源出错时，资源的描述会用于错误信息的输出。一般来说，资源的描述是一个完全限定的文件名称，或者是当前资源的真实 URL。

常见 Spring 资源接口：

内置的 Resource 实现

Spring 包括几个内置的 Resource 实现：

ResourceLoader 接口

ResourceLoader 接口用于加载 Resource 对象。其定义如下：

1
2
3
4
5
6

public interface ResourceLoader {

    Resource getResource(String location);

    ClassLoader getClassLoader();
}

Spring 中主要的 ResourceLoader 实现：

Spring 中，所有的 ApplicationContext 都实现了 ResourceLoader 接口。因此，所有 ApplicationContext 都可以通过 getResource() 方法获取 Resource 实例。

【示例】

1
2
3
4
5
6
7

// 如果没有指定资源前缀，Spring 会尝试返回合适的资源
Resource template = ctx.getResource("some/resource/path/myTemplate.txt");
// 如果指定 classpath: 前缀，Spring 会强制使用 ClassPathResource
Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt");
// 如果指定 file:、http 等 URL 前缀，Spring 会强制使用 UrlResource
Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt");
Resource template = ctx.getResource("http://myhost.com/resource/path/myTemplate.txt");

下表列举了 Spring 根据各种位置路径加载资源的策略：

ResourcePatternResolver 接口

ResourcePatternResolver 接口是 ResourceLoader 接口的扩展，它的作用是定义策略，根据位置模式解析 Resource 对象。

1
2
3
4
5
6

public interface ResourcePatternResolver extends ResourceLoader {

    String CLASSPATH_ALL_URL_PREFIX = "classpath*:";

    Resource[] getResources(String locationPattern) throws IOException;
}

PathMatchingResourcePatternResolver 是一个独立的实现，可以在 ApplicationContext 之外使用，也可以被 ResourceArrayPropertyEditor 用于填充 Resource[] bean 属性。PathMatchingResourcePatternResolver 能够将指定的资源位置路径解析为一个或多个匹配的 Resource 对象。

注意：任何标准 ApplicationContext 中的默认 ResourceLoader 实际上是 PathMatchingResourcePatternResolver 的一个实例，它实现了 ResourcePatternResolver 接口。

ResourceLoaderAware 接口

ResourceLoaderAware 接口是一个特殊的回调接口，用来标记提供 ResourceLoader 引用的对象。ResourceLoaderAware 接口定义如下：

1
2
3

public interface ResourceLoaderAware {
    void setResourceLoader(ResourceLoader resourceLoader);
}

当一个类实现 ResourceLoaderAware 并部署到应用程序上下文中（作为 Spring 管理的 bean）时，它会被应用程序上下文识别为 ResourceLoaderAware，然后，应用程序上下文会调用 setResourceLoader(ResourceLoader)，将自身作为参数提供（请记住，Spring 中的所有应用程序上下文都实现 ResourceLoader 接口）。

由于 ApplicationContext 是一个 ResourceLoader，该 bean 还可以实现 ApplicationContextAware 接口并直接使用提供的应用程序上下文来加载资源。 但是，一般来说，如果您只需要这些，最好使用专门的 ResourceLoader 接口。 该代码将仅耦合到资源加载接口（可以被视为实用程序接口），而不耦合到整个 Spring ApplicationContext 接口。

在应用程序中，还可以使用 ResourceLoader 的自动装配作为实现 ResourceLoaderAware 接口的替代方法。传统的构造函数和 byType 自动装配模式能够分别为构造函数参数或 setter 方法参数提供 ResourceLoader。 为了获得更大的灵活性（包括自动装配字段和多参数方法的能力），请考虑使用基于注解的自动装配功能。 在这种情况下，ResourceLoader 会自动连接到需要 ResourceLoader 类型的字段、构造函数参数或方法参数中，只要相关字段、构造函数或方法带有 @Autowired 注解即可。

资源依赖

如果 bean 本身要通过某种动态过程来确定和提供资源路径，那么 bean 可以使用 ResourceLoader 或 ResourcePatternResolver 接口来加载资源。 例如，考虑加载某种模板，其中所需的特定资源取决于用户的角色。 如果资源是静态的，完全消除 ResourceLoader 接口（或 ResourcePatternResolver 接口）的使用，让 bean 公开它需要的 Resource 属性，并期望将它们注入其中是有意义的。

使注入这些属性变得简单的原因是所有应用程序上下文都注册并使用一个特殊的 JavaBeans PropertyEditor，它可以将 String 路径转换为 Resource 对象。 例如，下面的 MyBean 类有一个 Resource 类型的模板属性。

【示例】

1
2
3

<bean id="myBean" class="example.MyBean">
    <property name="template" value="some/resource/path/myTemplate.txt"/>
</bean>

请注意，配置中引用的模板资源路径没有前缀，因为应用程序上下文本身将用作 ResourceLoader，资源本身将根据需要通过 ClassPathResource，FileSystemResource 或 ServletContextResource 加载，具体取决于上下文的确切类型。

如果需要强制使用特定的资源类型，则可以使用前缀。 以下两个示例显示如何强制使用 ClassPathResource 和 UrlResource（后者用于访问文件系统文件）。

1
2

<property name="template" value="classpath:some/resource/path/myTemplate.txt">
<property name="template" value="file:///some/resource/path/myTemplate.txt"/>

可以通过 @Value 注解加载资源文件 myTemplate.txt，示例如下：

1
2
3
4
5
6
7
8
9
10
11

@Component
public class MyBean {

    private final Resource template;

    public MyBean(@Value("${template.path}") Resource template) {
        this.template = template;
    }

    // ...
}