Java 字节码

字节码简介

什么是字节码

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

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

字节码文件结构

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

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

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

魔数

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

版本号

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

举例来说，如果版本号为：“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 文件中由这 3 项数据来确定这个类的继承关系。

字段表

字段表用于描述类和接口中声明的变量。包含类级变量以及实例级变量，但是不包含方法内部声明的局部变量。

字段表也分为两部分，第一部分为两个字节，描述字段个数；第二部分是每个字段的详细信息 fields_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 - 这两个比较好理解，对应的是类中的方法和属性。

工具

jclasslib - IDEA 插件，可以直观查看当前字节码文件的类信息、常量池、方法区等信息。

参考资料

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

JVM 实战

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

分库分表基本原理

1. 为何要分库分表

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

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

2. 分库分表原理

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

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

2.1. 垂直分片

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

（1）业务拆分

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

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

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

（2）访问频率拆分

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

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

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

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

2.2. 水平分片

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

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

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

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

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

2.3. 分库分表策略

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

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

2.3.1. 数值范围路由

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

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

优点：数据迁移很简单。

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

2.3.2. Hash 路由

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

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

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

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

2.3.3. 路由表

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

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

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

3. 迁移和扩容

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

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

3.1.1. 停机迁移/扩容流程

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

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

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

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

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

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

3.1.2. 停机迁移/扩容方案分析

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

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

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

3.2. 双写迁移

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

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

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

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

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

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

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

3.2.1. 双写迁移流程

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

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

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

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

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

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

3.3. 主从升级

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

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

3.3.1. 升级从库的流程

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

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

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

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

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

3.3.2. 升级从库方案分析

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

4. 分库分表的问题

4.1. 分布式 ID 问题

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

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

4.2. 分布式事务问题

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

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

4.3. 跨节点 Join 和聚合

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

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

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

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

4.4. 跨分片的排序分页

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

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

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

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

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

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

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

5. 中间件

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

• 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，然后大量项目直接透明使用即可。

6. 参考资料

• 后端存储实战课
• 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;
    }

    // ...
}

Spring 的 PropertyEditor 会根据资源文件的路径字符串，加载 Resource 对象，并将其注入到 MyBean 的构造方法。

如果想要加载多个资源文件，可以使用 classpath*: 前缀，例如：classpath*:/config/templates/*.txt。

1
2
3
4
5
6
7
8
9
10
11

@Component
public class MyBean {

    private final Resource[] templates;

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

    // ...
}

应用上下文和资源路径

构造应用上下文

应用上下文构造函数（针对特定的应用上下文类型）通常将字符串或字符串数组作为资源的位置路径，例如构成上下文定义的 XML 文件。

【示例】

1
2
3
4
5

ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");
ApplicationContext ctx = new FileSystemXmlApplicationContext("conf/appContext.xml");
ApplicationContext ctx = new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");
ApplicationContext ctx = new ClassPathXmlApplicationContext(
                new String[] {"services.xml", "daos.xml"}, MessengerService.class);

使用通配符构造应用上下文

ApplicationContext 构造器的中的资源路径可以是单一的路径（即一对一地映射到目标资源）；也可以是通配符形式——可包含 classpath*：也可以是前缀或 ant 风格的正则表达式（使用 spring 的 PathMatcher 来匹配）。

示例：

1

ApplicationContext ctx = new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

使用 classpath* 表示类路径下所有匹配文件名称的资源都会被获取(本质上就是调用了 ClassLoader.getResources(…) 方法），接着将获取到的资源组装成最终的应用上下文。

在位置路径的其余部分，classpath*: 前缀可以与 PathMatcher 结合使用，如：classpath*:META-INF/*-beans.xml。

问题

Spring 配置资源中有哪些常见类型？

• XML 资源
• Properties 资源
• YAML 资源

参考资料

• Spring 官方文档之 Core Technologies
• 《小马哥讲 Spring 核心编程思想》

版本管理中间件 Flyway

Flyway 是一个数据迁移工具。

简介

什么是 Flyway

Flyway 是一个开源的数据库迁移工具。

为什么要使用数据迁移

为了说明数据迁移的作用，我们来举一个示例：

（1）假设，有一个叫做 Shiny 的项目，它的架构是一个叫做 Shiny Soft 的 App 连接叫做 Shiny DB 的数据库。

（2）对于大多数项目而言，最简单的持续集成场景如下所示：

这意味着，我们不仅仅要处理一份环境中的修改，由此会引入一些版本冲突问题：

在代码侧（即应用软件）的版本问题比较容易解决：

• 有方便的版本控制工具
• 有可复用的构建和持续集成
• 规范的发布和部署过程

那么，数据库层面的版本问题如何解决呢？

目前仍然没有方便的数据库版本工具。许多项目仍使用 sql 脚本来解决版本冲突，甚至是遇到冲突问题时才想起用 sql 语句去解决。

由此，引发一些问题：

• 机器上的数据库是什么状态？
• 脚本到底生效没有？
• 生产环境修复的问题是否也在测试环境修复了？
• 如何建立一个新的数据库实例？

数据迁移就是用来搞定这些混乱的问题：

• 通过草稿重建一个数据库。
• 在任何时候都可以清楚的了解数据库的状态。
• 以一种明确的方式将数据库从当前版本迁移到一个新版本。

Flyway 如何工作？

最简单的场景是指定 Flyway 迁移到一个空的数据库。

Flyway 会尝试查找它的 schema 历史表，如果数据库是空的，Flyway 就不再查找，而是直接创建数据库。

现再你就有了一个仅包含一张空表的数据库，默认情况下，这张表叫 flyway_schema_history。

这张表将被用于追踪数据库的状态。

然后，Flyway 将开始扫描文件系统或应用 classpath 中的 migrations。这些 migrations 可以是 sql 或 java。

这些 migrations 将根据他们的版本号进行排序。

任意 migration 应用后，schema 历史表将更新。当元数据和初始状态替换后，可以称之为：迁移到新版本。

Flyway 一旦扫描了文件系统或应用 classpath 下的 migrations，这些 migrations 会检查 schema 历史表。如果它们的版本号低于或等于当前的版本，将被忽略。保留下来的 migrations 是等待的 migrations，有效但没有应用。

migrations 将根据版本号排序并按序执行。

快速上手

Flyway 有 4 种使用方式：

• 命令行
• JAVA API
• Maven
• Gradle

命令行

适用于非 Java 用户，无需构建。

1

> flyway migrate -url=... -user=... -password=...

（1）下载解压

进入官方下载页面，选择合适版本，下载并解压到本地。

（2）配置 flyway

编辑 /conf/flyway.conf：

1
2
3

flyway.url=jdbc:h2:file:./foobardb
flyway.user=SA
flyway.password=

（3）创建第一个 migration

在 /sql 目录下创建 V1__Create_person_table.sql 文件，内容如下：

1
2
3
4

create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

（4）迁移数据库

运行 Flyway 来迁移数据库：

1

flyway-5.1.4> flyway migrate

运行正常的情况下，应该可以看到如下结果：

1
2
3
4
5
6

Database: jdbc:h2:file:./foobardb (H2 1.4)
Successfully validated 1 migration (execution time 00:00.008s)
Creating Schema History table: "PUBLIC"."flyway_schema_history"
Current version of schema "PUBLIC": << Empty Schema >>
Migrating schema "PUBLIC" to version 1 - Create person table
Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.033s)

（5）添加第二个 migration

在 /sql 目录下创建 V2__Add_people.sql 文件，内容如下：

1
2
3

insert into PERSON (ID, NAME) values (1, 'Axel');
insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

运行 Flyway

1

flyway-5.1.4> flyway migrate

运行正常的情况下，应该可以看到如下结果：

1
2
3
4
5

Database: jdbc:h2:file:./foobardb (H2 1.4)
Successfully validated 2 migrations (execution time 00:00.018s)
Current version of schema "PUBLIC": 1
Migrating schema "PUBLIC" to version 2 - Add people
Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.016s)

JAVA API

（1）准备

• Java8+
• Maven 3.x

（2）添加依赖

在 pom.xml 中添加依赖：

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

<project ...>
    ...
    <dependencies>
        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
            <version>5.1.4</version>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <version>1.3.170</version>
        </dependency>
        ...
    </dependencies>
    ...
</project>

（3）集成 Flyway

添加 App.java 文件，内容如下：

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

import org.flywaydb.core.Flyway;

public class App {
    public static void main(String[] args) {
        // Create the Flyway instance
        Flyway flyway = new Flyway();

        // Point it to the database
        flyway.setDataSource("jdbc:h2:file:./target/foobar", "sa", null);

        // Start the migration
        flyway.migrate();
    }
}

（4）创建第一个 migration

添加 src/main/resources/db/migration/V1__Create_person_table.sql 文件，内容如下：

1
2
3
4

create table PERSON (
    ID int not null,
    NAME varchar(100) not null
);

（5）执行程序

执行 App#main：

运行正常的情况下，应该可以看到如下结果：

1
2
3
4

INFO: Creating schema history table: "PUBLIC"."flyway_schema_history"
INFO: Current version of schema "PUBLIC": << Empty Schema >>
INFO: Migrating schema "PUBLIC" to version 1 - Create person table
INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.062s).

（6）添加第二个 migration

添加 src/main/resources/db/migration/V2__Add_people.sql 文件，内容如下：

1
2
3

insert into PERSON (ID, NAME) values (1, 'Axel');
insert into PERSON (ID, NAME) values (2, 'Mr. Foo');
insert into PERSON (ID, NAME) values (3, 'Ms. Bar');

运行正常的情况下，应该可以看到如下结果：

1
2
3

INFO: Current version of schema "PUBLIC": 1
INFO: Migrating schema "PUBLIC" to version 2 - Add people
INFO: Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.090s).

Maven

与 Java API 方式大体相同，区别在 集成 Flyway 步骤：

Maven 方式使用插件来集成 Flyway：

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

<project xmlns="...">
    ...
    <build>
        <plugins>
            <plugin>
                <groupId>org.flywaydb</groupId>
                <artifactId>flyway-maven-plugin</artifactId>
                <version>5.1.4</version>
                <configuration>
                    <url>jdbc:h2:file:./target/foobar</url>
                    <user>sa</user>
                </configuration>
                <dependencies>
                    <dependency>
                        <groupId>com.h2database</groupId>
                        <artifactId>h2</artifactId>
                        <version>1.4.191</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>
</project>

因为用的是插件，所以执行方式不再是运行 Java 类，而是执行 maven 插件：

1

> mvn flyway:migrate

:point_right: 参考：示例源码

Gradle

本人不用 Gradle，略。

入门篇

概念

Migrations

在 Flyway 中，对于数据库的任何改变都称之为 Migrations。

Migrations 可以分为 Versioned migrations 和 Repeatable migrations。

Versioned migrations 有 2 种形式：regular 和 undo。

Versioned migrations 和 Repeatable migrations 都可以使用 SQL 或 JAVA 来编写。

Versioned migrations

由一个版本号（version）、一段描述（description）、一个校验（checksum）组成。版本号必须是惟一的。Versioned migrations 只能按顺序执行一次。

一般用于：

• 增删改 tables/indexes/foreign keys/enums/UDTs。
• 引用数据更新
• 用户数据校正

Regular 示例：

1
2
3
4
5
6
7
8
9

CREATE TABLE car (
    id INT NOT NULL PRIMARY KEY,
    license_plate VARCHAR NOT NULL,
    color VARCHAR NOT NULL
);

ALTER TABLE owner ADD driver_license_id VARCHAR;

INSERT INTO brand (name) VALUES ('DeLorean');

Undo migrations

注：仅专业版支持

Undo Versioned Migrations 负责撤销 Regular Versioned migrations 的影响。

Undo 示例：

1
2
3
4
5

DELETE FROM brand WHERE name='DeLorean';

ALTER TABLE owner DROP driver_license_id;

DROP TABLE car;

Repeatable migrations

由一段描述（description）、一个校验（checksum）组成。Versioned migrations 每次执行后，校验（checksum）会更新。

Repeatable migrations 用于管理可以通过一个文件来维护版本控制的数据库对象。

一般用于：

• 创建（重建）views/procedures/functions/packages 等。
• 大量引用数据重新插入

示例：

1
2

CREATE OR REPLACE VIEW blue_cars AS
    SELECT id, license_plate FROM cars WHERE color='blue';

基于 SQL 的 migrations

migrations 最常用的编写形式就是 SQL。

基于 SQL 的 migrations 一般用于：

• DDL 变更（针对 TABLES,VIEWS,TRIGGERS,SEQUENCES 等的 CREATE/ALTER/DROP 操作）
• 简单的引用数据变更（引用数据表中的 CRUD）
• 简单的大量数据变更（常规数据表中的 CRUD）

命名规则

为了被 Flyway 自动识别，SQL migrations 的文件命名必须遵循规定的模式：

• Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
• Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
• Separator - __ (两个下划线) (可配置)
• Description - 下划线或空格分隔的单词
• Suffix - .sql (可配置)

基于 JAVA 的 migrations

基于 JAVA 的 migrations 适用于使用 SQL 不容易表达的场景：

• BLOB 和 CLOB 变更
• 大量数据的高级变更（重新计算、高级格式变更）

命名规则

为了被 Flyway 自动识别，JAVA migrations 的文件命名必须遵循规定的模式：

• Prefix - V 代表 versioned migrations (可配置), U 代表 undo migrations (可配置)、 R 代表 repeatable migrations (可配置)
• Version - 版本号通过.(点)或_(下划线)分隔 (repeatable migrations 不需要)
• Separator - __ (两个下划线) (可配置)
• Description - 下划线或空格分隔的单词

:point_right: 更多细节请参考：https://flywaydb.org/documentation/migrations

Callbacks

注：部分 events 仅专业版支持。

尽管 Migrations 可能已经满足绝大部分场景的需要，但是某些情况下需要你一遍又一遍的执行相同的行为。这可能会重新编译存储过程，更新视图以及许多其他类型的开销。

因为以上原因，Flyway 提供了 Callbacks，用于在 Migrations 生命周期中添加钩子。

Callbacks 可以用 SQL 或 JAVA 来实现。

SQL Callbacks

SQL Callbacks 的命名规则为：event 名 + SQL migration。

如： beforeMigrate.sql, beforeEachMigrate.sql, afterEachMigrate.sql 等。

SQL Callbacks 也可以包含描述（description）。这种情况下，SQL Callbacks 文件名 = event 名 + 分隔符 + 描述 + 后缀。例：beforeRepair__vacuum.sql

当同一个 event 有多个 SQL callbacks，将按照它们描述（description）的顺序执行。

注： Flyway 也支持你配置的 sqlMigrationSuffixes。

JAVA Callbacks

当 SQL Callbacks 不够方便时，才应考虑 JAVA Callbacks。

JAVA Callbacks 有 3 种形式：

1. 基于 Java 的 Migrations - 实现 JdbcMigration、SpringJdbcMigration、MigrationInfoProvider、MigrationChecksumProvider、ConfigurationAware、FlywayConfiguration
2. 基于 Java 的 Callbacks - 实现 org.flywaydb.core.api.callback 接口。
3. 自定义 Migration resolvers 和 executors - 实现 MigrationResolver、MigrationExecutor、ConfigurationAware、FlywayConfiguration 接口。

:point_right: 更多细节请参考：https://flywaydb.org/documentation/callbacks

Error Handlers

注：仅专业版支持。

（略）

Dry Runs

注：仅专业版支持。

（略）

命令

Flyway 的功能主要围绕着 7 个基本命令：Migrate、Clean、Info、Validate、Undo、Baseline 和 Repair。

注：各命令的使用方法细节请查阅官方文档。

支持的数据库

• Oracle
• SQL Server
• DB2
• MySQL
• MariaDB
• PostgreSQL
• Redshift
• CockroachDB
• SAP HANA
• Sybase ASE
• Informix
• H2
• HSQLDB
• Derby
• SQLite

资料

| Github | 官方文档 |

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

Cassandra

Apache Cassandra 是一个高度可扩展的分区行存储。行被组织成具有所需主键的表。

最新版本：v4.0

Quick Start

安装

先决条件

• JDK8+
• Python 2.7

简介

Apache Cassandra 是一套开源分布式 Key-Value 存储系统。它最初由 Facebook 开发，用于储存特别大的数据。

特性

主要特性

• 分布式
• 基于 column 的结构化
• 高伸展性

Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作，会被复制到其他节点上去，对 Cassandra 的读操作，也会被路由到某个节点上面去读取。对于一个 Cassandra 群集来说，扩展性能 是比较简单的事情，只管在群集里面添加节点就可以了。

突出特性

• 模式灵活 - 使用 Cassandra，像文档存储，不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部署上。
• 真正的可扩展性 - Cassandra 是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。
• 多数据中心识别 - 你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。
• 范围查询 - 如果你不喜欢全部的键值查询，则可以设置键的范围来查询。
• 列表数据结构 - 在混合模式可以将超级列添加到 5 维。对于每个用户的索引，这是非常方便的。
• 分布式写操作 - 有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

更多内容

• Cassandra 官网
• Cassandra Github

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

PostgreSQL 应用指南

PostgreSQL 是一个关系型数据库（RDBM）。

关键词：Database, RDBM, psql

安装

本文仅以运行在 Centos 环境下举例。

进入官方下载页面，根据操作系统选择合适版本。

官方下载页面要求用户选择相应版本，然后动态的给出安装提示，如下图所示：

前 3 步要求用户选择，后 4 步是根据选择动态提示的安装步骤

（1）选择 PostgreSQL 版本

（2）选择平台

（3）选择架构

（4）安装 PostgreSQL 的 rpm 仓库（为了识别下载源）

1

yum install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-2.noarch.rpm

（5）安装客户端

1

yum install postgresql10

（6）安装服务端（可选的）

1

yum install postgresql10-server

（7）设置开机启动（可选的）

1
2
3

/usr/pgsql-10/bin/postgresql-10-setup initdb
systemctl enable postgresql-10
systemctl start postgresql-10

添加新用户和新数据库

初次安装后，默认生成一个名为 postgres 的数据库和一个名为 postgres 的数据库用户。这里需要注意的是，同时还生成了一个名为 postgres 的 Linux 系统用户。

首先，新建一个 Linux 新用户，可以取你想要的名字，这里为 dbuser。

1

sudo adduser dbuser

使用 psql 命令登录 PostgreSQL 控制台：

1

sudo -u postgres psql

这时相当于系统用户 postgres 以同名数据库用户的身份，登录数据库，这是不用输入密码的。如果一切正常，系统提示符会变为”postgres=#”，表示这时已经进入了数据库控制台。以下的命令都在控制台内完成。

（1）使用 \password 命令，为 postgres 用户设置一个密码。

1

postgres=# \password postgres

（2）创建数据库用户 dbuser（刚才创建的是 Linux 系统用户），并设置密码。

1

CREATE USER dbuser WITH PASSWORD 'password';

（3）创建用户数据库，这里为 exampledb，并指定所有者为 dbuser。

1

CREATE DATABASE exampledb OWNER dbuser;

（4）将 exampledb 数据库的所有权限都赋予 dbuser，否则 dbuser 只能登录控制台，没有任何数据库操作权限。

1

GRANT ALL PRIVILEGES ON DATABASE exampledb to dbuser;

（5）使用\q 命令退出控制台（也可以直接按 ctrl+D）。

登录数据库

添加新用户和新数据库以后，就要以新用户的名义登录数据库，这时使用的是 psql 命令。

1

psql -U dbuser -d exampledb -h 127.0.0.1 -p 5432

上面命令的参数含义如下：-U 指定用户，-d 指定数据库，-h 指定服务器，-p 指定端口。

输入上面命令以后，系统会提示输入 dbuser 用户的密码。输入正确，就可以登录控制台了。

psql 命令存在简写形式。如果当前 Linux 系统用户，同时也是 PostgreSQL 用户，则可以省略用户名（-U 参数的部分）。举例来说，我的 Linux 系统用户名为 ruanyf，且 PostgreSQL 数据库存在同名用户，则我以 ruanyf 身份登录 Linux 系统后，可以直接使用下面的命令登录数据库，且不需要密码。

1

psql exampledb

此时，如果 PostgreSQL 内部还存在与当前系统用户同名的数据库，则连数据库名都可以省略。比如，假定存在一个叫做 ruanyf 的数据库，则直接键入 psql 就可以登录该数据库。

psql

另外，如果要恢复外部数据，可以使用下面的命令。

1

psql exampledb < exampledb.sql

控制台命令

除了前面已经用到的 \password 命令（设置密码）和 \q 命令（退出）以外，控制台还提供一系列其他命令。

1
2
3
4
5
6
7
8
9
10

\password           设置密码
\q                  退出
\h                  查看SQL命令的解释，比如\h select
\?                  查看psql命令列表
\l                  列出所有数据库
\c [database_name]  连接其他数据库
\d                  列出当前数据库的所有表格
\d [table_name]     列出某一张表格的结构
\x                  对数据做展开操作
\du                 列出所有用户

数据库操作

基本的数据库操作，就是使用一般的 SQL 语言。

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

# 创建新表
CREATE TABLE user_tbl(name VARCHAR(20), signup_date DATE);
# 插入数据
INSERT INTO user_tbl(name, signup_date) VALUES('张三', '2013-12-22');
# 选择记录
SELECT * FROM user_tbl;
# 更新数据
UPDATE user_tbl set name = '李四' WHERE name = '张三';
# 删除记录
DELETE FROM user_tbl WHERE name = '李四' ;
# 添加栏位
ALTER TABLE user_tbl ADD email VARCHAR(40);
# 更新结构
ALTER TABLE user_tbl ALTER COLUMN signup_date SET NOT NULL;
# 更名栏位
ALTER TABLE user_tbl RENAME COLUMN signup_date TO signup;
# 删除栏位
ALTER TABLE user_tbl DROP COLUMN email;
# 表格更名
ALTER TABLE user_tbl RENAME TO backup_tbl;
# 删除表格
DROP TABLE IF EXISTS backup_tbl;

备份和恢复

1
2

pg_dump --format=t -d db_name -U user_name -h 127.0.0.1 -O -W  > dump.sql
psql -h 127.0.0.1 -U user_name db_name < dump.sql

参考资料

• https://www.postgresql.org/download/
• http://www.ruanyifeng.com/blog/2013/12/getting_started_with_postgresql.html

🚪 传送

◾ 💧 钝悟的 IT 知识图谱 ◾

H2 应用指南

概述

H2 是一个开源的嵌入式数据库引擎，采用 java 语言编写，不受平台的限制。同时 H2 提供了一个十分方便的 web 控制台用于操作和管理数据库内容。H2 还提供兼容模式，可以兼容一些主流的数据库，因此采用 H2 作为开发期的数据库非常方便。

使用说明

H2 控制台应用

H2 允许用户通过浏览器接口方式访问 SQL 数据库。

1. 进入官方下载地址，选择合适版本，下载并安装到本地。
2. 启动方式：在 bin 目录下，双击 jar 包；执行 java -jar h2*.jar；执行脚本：h2.bat 或 h2.sh。
3. 在浏览器中访问：http://localhost:8082，应该可以看到下图中的页面：

点击 Connect ，可以进入操作界面：

操作界面十分简单，不一一细说。

嵌入式应用

JDBC API

1
2
3

Connection conn = DriverManager.
    getConnection("jdbc:h2:~/test");
conn.close();

详见：Using the JDBC API

连接池

1
2
3
4
5

import org.h2.jdbcx.JdbcConnectionPool;
JdbcConnectionPool cp = JdbcConnectionPool.
create("jdbc:h2:~/test", "sa", "sa");
Connection conn = cp.getConnection();
conn.close(); cp.dispose();

详见：Connection Pool

Maven

1
2
3
4
5

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.197</version>
</dependency>

详见：Maven 2

Hibernate

hibernate.cfg.xml (or use the HSQLDialect):

1
2
3

<property name="dialect">
    org.hibernate.dialect.H2Dialect
</property>

详见：Hibernate

TopLink 和 Glassfish

Datasource class: org.h2.jdbcx.JdbcDataSource
oracle.toplink.essentials.platform.database.H2Platform

详见：TopLink and Glassfish

运行方式

嵌入式

数据库持久化存储为单个文件。

连接字符串：\~/.h2/DBName 表示数据库文件的存储位置，如果第一次连接则会自动创建数据库。

• jdbc:h2:\~/test - ‘test’ 在用户根目录下
• jdbc:h2:/data/test - ‘test’ 在 /data 目录下
• jdbc:h2:test - ‘test’ 在当前工作目录

内存式

数据库只在内存中运行，关闭连接后数据库将被清空，适合测试环境

连接字符串：jdbc:h2:mem:DBName;DB_CLOSE_DELAY=-1

如果不指定 DBName，则以私有方式启动，只允许一个连接。

• jdbc:h2:mem:test - 一个进程中有多个连接
• jdbc:h2:mem: - 未命名的私有库，一个连接

服务模式

H2 支持三种服务模式：

• web server：此种运行方式支持使用浏览器访问 H2 Console
• TCP server：支持客户端/服务器端的连接方式
• PG server：支持 PostgreSQL 客户端

启动 tcp 服务连接字符串示例：

• jdbc:h2:tcp://localhost/\~/test - 用户根目录
• jdbc:h2:tcp://localhost//data/test - 绝对路径

启动服务

执行 java -cp *.jar org.h2.tools.Server

执行如下命令，获取选项列表及默认值

1

java -cp h2*.jar org.h2.tools.Server -?

常见的选项如下：

• -web：启动支持 H2 Console 的服务
• -webPort <port>：服务启动端口，默认为 8082
• -browser：启动 H2 Console web 管理页面
• -tcp：使用 TCP server 模式启动
• -pg：使用 PG server 模式启动

设置

• jdbc:h2:..;MODE=MySQL 兼容模式（或 HSQLDB 等）
• jdbc:h2:..;TRACE_LEVEL_FILE=3 记录到 *.trace.db

连接字符串参数

• DB_CLOSE_DELAY - 要求最后一个正在连接的连接断开后，不要关闭数据库
• MODE=MySQL - 兼容模式，H2 兼容多种数据库，该值可以为：DB2、Derby、HSQLDB、MSSQLServer、MySQL、Oracle、PostgreSQL
• AUTO_RECONNECT=TRUE - 连接丢失后自动重新连接
• AUTO_SERVER=TRUE - 启动自动混合模式，允许开启多个连接，该参数不支持在内存中运行模式
• TRACE_LEVEL_SYSTEM_OUT、TRACE_LEVEL_FILE - 输出跟踪日志到控制台或文件， 取值 0 为 OFF，1 为 ERROR（默认值），2 为 INFO，3 为 DEBUG
• SET TRACE_MAX_FILE_SIZE mb - 设置跟踪日志文件的大小，默认为 16M

maven 方式

此外，使用 maven 也可以启动 H2 服务。添加以下插件

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

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>exec-maven-plugin</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>java</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <mainClass>org.h2.tools.Server</mainClass>
    <arguments>
      <argument>-web</argument>
      <argument>-webPort</argument>
      <argument>8090</argument>
      <argument>-browser</argument>
    </arguments>
  </configuration>
</plugin>

在命令行中执行如下命令启动 H2 Console

1

mvn exec:java

或者建立一个 bat 文件

1
2
3

@echo off
call mvn exec:java
pause

此操作相当于执行了如下命令：

1

java -jar h2-1.3.168.jar -web -webPort 8090 -browser

Spring 整合 H2

（1）添加依赖

1
2
3
4
5

<dependency>
  <groupId>com.h2database</groupId>
  <artifactId>h2</artifactId>
  <version>1.4.194</version>
</dependency>

（2）spring 配置

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jdbc="http://www.springframework.org/schema/jdbc"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
            http://www.springframework.org/schema/jdbc
            http://www.springframework.org/schema/jdbc/spring-jdbc.xsd">

  <!--配置数据源-->
  <bean id="dataSource" class="org.h2.jdbcx.JdbcConnectionPool"
        destroy-method="dispose">
    <constructor-arg>
      <bean class="org.h2.jdbcx.JdbcDataSource">
        <!-- 内存模式 -->
        <property name="URL" value="jdbc:h2:mem:test"/>
        <!-- 文件模式 -->
        <!-- <property name="URL" value="jdbc:h2:testRestDB" /> -->
        <property name="user" value="root"/>
        <property name="password" value="root"/>
      </bean>
    </constructor-arg>
  </bean>

  <!-- JDBC模板 -->
  <bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
    <constructor-arg ref="dataSource"/>
  </bean>
  <bean id="myJdbcTemplate" class="org.zp.notes.spring.jdbc.MyJdbcTemplate">
    <property name="jdbcTemplate" ref="jdbcTemplate"/>
  </bean>

  <!-- 初始化数据表结构 -->
  <jdbc:initialize-database data-source="dataSource" ignore-failures="ALL">
    <jdbc:script location="classpath:sql/h2/create_table_student.sql"/>
  </jdbc:initialize-database>
</beans>