我的电脑在启动时总会提示“Failed to start Load Kernel Modules"：

虽然不影响使用，可强迫症看了还是会觉得难受。所以，还是着手解决下，顺便总结下Linux下service启动失败时一般的排查方法。

这个问题是systemd-modules-load.service启动失败，因为 Failed to find module 'vfs_monitor'，下面给出排查过程和解决方案。

对于内网服务器，如果我们想从外网访问，可以借助一台拥有外网IP的云服务器，通过建立SSH反向隧道来实现访问内网服务器。

SSH隧道​

首先，修改云服务器的/etc/ssh/sshd_config，在该文件的最后添加：

GatewayPorts yes
ClientAliveInterval 60
ClientAliveCountMax 3

然后重启云服务器的sshd服务使上述配置生效：

$ sudo systemctl restart sshd

如果不进行上述配置，将只有登录云服务器才可以外网访问内网服务器。

然后，内网服务器向云服务器主动建立SSH连接，并将内网服务器的22号端口转发到转发端口（任一空闲端口即可）：

$ ssh -NR 转发端口:localhost:22 云服务器用户名@云服务器IP -p 云服务器SSH端口

注意，需要在云服务器的控制台配置允许转发端口的访问。

云服务器SSH端口默认是22号端口，如果你修改了SSH连接的默认端口号，需要使用-p参数指明端口号，否则可以省略-p 云服务器SSH端口。

今天偶然看了下服务器上的日志，结果发现有人在暴力尝试SSH登录：

因为服务器是实验室内部使用，只有校园网才能连接，所以在服务器的安全上就没怎么在意。见此状况，立刻用iptables禁掉了一些IP，比如说禁掉148.235.57.190：

Survivor的作用​

当没有Survivor时，如果增加老年代空间，需要更多存活对象才能填满老年代，这样可以降低Full GC的频率；但是，随着老年代空间加大，一旦发生Full GC，执行所需要的时间更长。

如果减少老年代空间，虽然Full GC所需时间减少；但是，老年代很快被存活对象填满，Full GC频率增加。

因此，Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生。

为什么要两个Survivor​

解释一：为了解决碎片化。如果只有一个Survivor，对象在Eden创建，GC时存活对象复制到Survivor，当下次GC时，没有一个空闲的Survivor，而Survivor中也会有可回收对象，这样在Survivor中就出现了大量的空闲碎片。如果有两个Survivor，每次GC将Eden和其中一个Survivor中的存活对象复制到另一个Survivor，前一个Survivor会因此空闲，于是下次GC可以重复这样的过程，从而解决了碎片化。

解释二：复制算法将内存等分为两块，每次只使用其中一块，GC时将存活对象移至另一块，前一块因此空闲。引入Eden可以视为对内存利用的优化，相当于两个Survivor共享的区域，每次GC后Eden都会因此空闲，这样相当于扩大了Survivor，避免频繁GC。

SpringBoot工程​

建立初始SpringBoot工程的两种方式：

1、https://start.spring.io/

2、使用IntelliJ IDEA的Spring Initializer：