张天赐的小世界

JDK 17 营销初体验 —— 亚毫秒停顿 ZGC 落地实践

Tue, 30 Apr 2024 15:51:00 +0800

前言

自 2014 年发布以来， JDK 8 一直都是相当热门的 JDK 版本。其原因就是对底层数据结构、JVM 性能以及开发体验做了重大升级，得到了开发人员的认可。但距离 JDK 8 发布已经过去了 9 年，那么这 9 年的时间，JDK 做了哪些升级？是否有新的重大特性值得我们尝试？能否解决一些我们现在苦恼的问题？带着这份疑问，我们进行了 JDK 版本的调研与尝试。

新特性一览

现如今的 JDK 发布节奏变快，每次新出一个版本，我们就会感叹一下：我还在用 JDK 8，现在都 JDK 9、10、11 …… 21 了？然后就会瞅瞅又多了哪些新特性。有一些新特性很香，但考虑一番还是决定放弃升级。主要原因除了新增特性对我们来说改变不大以外，最重要的就是 JDK 9 带来的模块化（JEP 200），导致我们升级十分困难。

模块化的本意是将 JDK 划分为一组模块，这些模块可以在编译时、构建时和运行时组合成各种配置，主要目标是使实现更容易扩展到小型设备，提高安全性和可维护性，并提高应用程序性能。但付出的代价非常大，最直观的影响就是，一些 JDK 内部类不能访问了。

但是除此之外，并没有太多阻塞升级的问题，后续版本都是一些很香的特性：

G1 （JEP 248、JEP 307、JEP 344、JEP 345、JEP 346），提供一个支持指定暂停时间、NUMA 感知内存分配的高性能垃圾回收器
ZGC （JEP 333、JEP 376、JEP 377），一个支持 NUMA，暂停时间不应超过 1ms 的垃圾回收器
并发 API 更新（JEP 266），提供 publish-subscribe 框架，支持响应式流发布 - 订阅框架的接口，以及 CompletableFuture 的进一步完善
集合工厂方法（JEP 269），类似 Guava，支持快速创建有初始元素的集合
新版 HTTP 客户端（JEP 321），一个现代化、支持异步、WebSocket、响应式流的 JDK 内置 API
空指针 NPE 直接给出异常方法位置（JEP 358），以前只给代码行数，不告诉哪个方法，一行多个方法的写法一但出现空指针，全靠程序员上下文分析推理
instanceof 的模式匹配（JEP 394），判断类型后再也不用强转了
数据记录类（JEP 395），一个标准的值聚合类，帮助程序员专注于对不可变数据进行建模，实现数据驱动
Switch 表达式语法改进（JEP 361），改变 Switch 又臭又长，易于出错的现状
文本块（JEP 378），支持二维文本块，而不是像现在一样通过 + 号自行拼接
密封类（JEP 409），提供一种限制进行扩展的语法，超类应该可以被广泛访问（因为它代表了用户的重要抽象），但不能广泛扩展（因为它的子类应该仅限于作者已知的子类）
以及一些未提到的底层数据结构优化，JVM 性能提升……

这么多的优点，恰好能解决我们当前遇到的一些问题，因此我们决定进行 JDK 升级。

升级

升级应用评估

首先自然是要考虑要将哪些应用进行升级。我们根据以下条件进行应用筛选：

第一，也是最重要的一点，此系统可以通过升级，解决现有问题与瓶颈
第二，有完备的机制能够进行快速回归与验证，如完备的单元测试，自动化测试覆盖能力，便捷的生产压测能力等，底层的升级一定要做好完备的验证
第三，技术债务一定要少，不至于在升级过程中遇到一些必须解决的技术债，给升级增加难度
第四，负责升级的人对这个系统都很了解，除核心业务逻辑外，还能够了解引入了哪些中间件与依赖，使用了中间件的哪些功能，中间件升级后，大量不兼容的改动是否对现有系统造成影响

最终我们选取了一个结算页、收银台展示无券支付营销的应用进行升级。此应用特点如下：

作为核心链路的应用之一，接口响应时间要求很高，GC 是其耗时抖动的瓶颈之一
业务正在进行快速迭代发展，随着降本增效策略的落地，营销策略进一步精细化，营销种类、数量、范围进一步增加，给系统性能带来更大的挑战
日常流量不低，整点存在突发流量，并且需要承接大促流量
核心链路覆盖了单元测试，测试环境具备自动化回归能力，预发、生产支持常态化压测与生产流量回放
非 Web 应用，仅使用各个中间件的基础功能，升级出现不兼容的问题小
维护了 3 年，经历过多次重构，历史问题较少，几乎没有技术债务

针对以上特点，此应用很适合进行 JDK 17 升级。此应用基于 JDK 8，SpringBoot 2.0.8，除常见外部基础组件外，还使用以下公司内部中间件：UMP、SGM、DUCC、CDS、JMQ、JSF、R2M。

升级效果

可以先看下我们升级后压测的效果：

纯计算代码不再受 GC 影响

升级前

升级后

升级后吞吐量几乎不受影响（甚至提升 0.01%），GC 平均耗时下降 1405 倍，GC 最大耗时下降 1132 倍

升级步骤

升级 JDK 编译版本

首先自然是修改 maven 中指定的 JDK 版本，可以先升级到 JDK 11，同时修改 maven 编译插件

11
3.8.1  
3.2.1  
3.3.2  
2.22.2

  
    org.apache.maven.plugins  
    maven-compiler-plugin  
    ${maven-compiler-plugin.version}  
            
        ${java.version}  
        ${project.build.sourceEncoding}

引入缺少的依赖

然后就可以进行本地编译了，此时会暴露一些很简单的问题，比如找不到包、类等等。原因就是 JDK 11 移除了 Java EE and CORBA 的模块，需要手动引入。

  
  
    javax.annotation  
    javax.annotation-api  
    1.3.1  
  
  
    javax.xml.bind  
    jaxb-api  
    2.3.0  
  
  
    com.sun.xml.bind  
    jaxb-impl  
    2.3.0  
  
  
    com.sun.xml.bind  
    jaxb-core  
    2.3.0  
  
  
    javax.activation  
    activation  
    1.0.2

升级外部中间件

解决了编译找不到类的问题，接下来就该升级依赖的外部中间件了。对于我们的应用来说，也就是升级 SpringBoot 的版本。支持 JDK 17 的版本是 Spring 5.3，对应 SpringBoot 2.5。

在这里我建议升级至 SpringBoot 2.7，从 2.5 升级至 2.7 几乎没有需要改动的地方，同时高版本的 SprngBoot 所约定的依赖，对 JDK 17 的支持也更好。

建议进行大版本逐个升级，比如我们从 2.0 升级至 2.1。每升一个版本，就要仔细观察依赖版本的变化，掌握每个依赖升级的情况。SpringBoot 的升级其实意味着把所有开源组件约定版本进行大版本升级，接口弃用，破坏性兼容更新较多，需要一一鉴别。

下面以升级 Spring Boot 2.1 为例，说明我们升级的步骤：

首先阅读 Spring Boot 2.1 做了哪些和我们有关的配置改动
禁用了同 Bean 覆盖，开启需要指定 spring.main.allow-bean-definition-overriding 为 true
然后阅读 Spring Boot 2.1 升级了哪些我们用到的依赖
- Spring 升级至 5.1
  - 首先阅读 Spring 5.1 做了哪些和我们有关的配置改动：无影响
  - 然后阅读 Spring 5.1 升级了哪些我们用到的依赖
    - ASM 7.0：同理，阅读升级影响（这种底层依赖的底层依赖，如果仅 ASM 在使用，则无需关心）
    - CGLIB 3.2：同理，阅读升级影响（这种底层依赖的底层依赖，如果仅 ASM 在使用，则无需关心）
  - 最后阅读 Spring 5.1 弃用了哪些和我们有关的配置与依赖：无影响
- Lombok 升级至 1.18
  - 阅读改动影响，1.18 Lombok 默认情况下将不再生成私有无参构造函数。可以通过在 lombok.config 配置文件中设置 lombok.noArgsConstructor.extraPrivate=true 来启用它
- Hibernate 升级至 5.3：阅读改动影响，对我们项目无影响
- JUnit 升级至 5.2：阅读改动影响，需要 Surefire 插件升级至 2.21.0 及以上
最后阅读 Spring Boot 2.1 弃用了哪些和我们有关的配置与依赖

至此，Spring Boot 2.1 升级完毕。接下来分析一次依赖树变化，和升级前的依赖树进行比较，查看依赖变化范围是否全部已知可控。完成后进行 Spring Boot 2.2 的升级。

以下为我们需要注意的升级事项，仅供参考：

可以先升级到 JDK 11，一边启动一边验证。但不要在 JDK 11 使用 ZGC，ZGC 的堆预留与可用堆的比例太大，有时会导致 OOM
代码中存在同 Bean，启动时 Springboot 2.0 会自动进行覆盖，高版本开启覆盖，需要指定 spring.main.allow-bean-definition-overriding 为 true
Spring Boot 2.2 默认的单元测试 Junit 升级至 5，Junit 4 的单元测试建议进行升级，改动不大
Spring Boot 2.4 不再支持 Junit 4 的单元测试，如果需要可以手动引入 Vintage 引擎
Spring Boot 2.4 配置文件处理逻辑变更，注意阅读更新日志
Spring Boot 2.6 默认禁用 Bean 循环依赖，可以通过将 spring.main.allow-circular-references 设置为 true 开启
Spring Boot 2.7 自动配置注册文件变更，spring.factories 中的内容需要移动至 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件下
spring-boot-properties-migrator 可以识别弃用的属性，可以考虑使用
Spring Framework 5.2 需要 Jackson 2.9.7+，注意阅读更新日志
Spring Framework 5.2 注解检索算法重构，所有自定义注释都必须使用 @Retention(RetentionPolicy.RUNTIME) 进行注释，以便 Spring 能够找到它们
Spring Framework 5.3 修改了很多东西，但都与我们的应用无关，请关注更新日志
ASM 仅单元测试 Mock 在使用，无需特殊关注，做好 JUnit 升级兼容即可
CGLIB 大版本升级以兼容字节码版本为主，关注好变更日志即可
Lombok 即使是小版本升级，也会有破坏性更新，需要仔细阅读每个版本的更新日志，建议少用 Lombok
Hibernate 没有太大的破坏性更新，关注好变更日志即可
JUnit 升级主要关注大版本变更，如 4 升 5，小版本没有特别大的破坏性更新，并且是单元测试使用的依赖，可以放心升级或者不升级
Jackson 2.11，对 java.util.Date 和 java.util.Calendar 默认格式进行了更改，注意查看更新日志进行兼容
注意字节码增强相关依赖的升级
注意本地缓存升级
注意 Netty 升级，关注更新日志

升级内部中间件

内部中间件升级较为简单，主要是关注 JMQ、JSF 版本。其中 JSF 依赖的 Netty 和 Javassist 等都需要升级，Netty 版本较低会有内存泄漏问题。

我们使用的依赖版本

给大家参考下我们升级后的依赖版本

  
        
    17  
    UTF-8  
    3.11.0  
    2.22.2  
    0.8.10  
    2.4.1  
    3.1.0  
    src/main/profiles  
    2.7.13  
    2.18.0-jdsec.rc2  
    5.2.4.Final  
    3.2.2  
    4.4  
    3.9.0.Final  
    4.1.36.Final  
    3.29.2-GA  
    23.0  
    5.1.29  
    1.36  
    3.1.6  
    1.2.83-jdsec.rc1  
    2.0.35  
    0.9.44  
    3.4.4  
    2.3.8  
    2.3.0.1  
    1.1.1  
      

        
    20221231.1  
    1.0.20  
    2.21.1  
    3.8.3  
    2.3.3-RC2  
    1.7.6-HOTFIX-T2  
    3.3.4

JVM 启动参数升级

远程 DEBUG 参数有所变化：

JAVA_DEBUG_OPTS=" -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000 "

打印 GC 日志参数的变化，我们在预发环境开启了日志进行观察：

JAVA_GC_LOG_OPTS=" -Xlog:gc*:file=/export/logs/gc.log:time,tid,tags:filecount=10:filesize=10m "

使用了 ZGC 的部分 JVM 参数：

JAVA_MEM_OPTS=" -server -Xmx12g -Xms12g -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:MaxDirectMemorySize=2048m -XX:+UseZGC -XX:ZAllocationSpikeTolerance=3 -XX:ParallelGCThreads=8 -XX:CICompilerCount=3 -XX:-RestrictContended -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/logs "

内部依赖需要访问 JDK 模块，如 UMP、JSF、虫洞、MyBatis、DUCC、R2M、SGM：

if [[ "$JAVA_VERSION" -ge 11 ]]; then  
  SGM_OPTS="${SGM_OPTS} --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED --add-opens java.management/sun.management=ALL-UNNAMED --add-opens java.management/java.lang.management=ALL-UNNAMED "
  UMP_OPT=" --add-opens java.base/sun.net.util=ALL-UNNAMED " 
  JSF_OPTS=" --add-opens java.base/sun.util.calendar=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.math=ALL-UNNAMED"  
  WORMHOLE_OPT=" --add-opens java.base/sun.security.action=ALL-UNNAMED "  
  MB_OPTS=" --add-opens java.base/java.lang=ALL-UNNAMED "  
  DUC_OPT=" --add-opens java.base/java.net=ALL-UNNAMED "  
  R2M_OPT=" --add-opens java.base/java.time=ALL-UNNAMED "  
fi

启动后完整的启动参数如下：

-javaagent:/export/package/sgm-probe-java/sgm-probe-5.9.5-product/sgm-agent-5.9.5.jar -Dsgm.server.address=http://sgm.jdfin.local -Dsgm.app.name=market-reduction-center -Dsgm.agent.sink.http.connection.requestTimeout=2000 -Dsgm.agent.sink.http.connection.connectTimeout=2000 -Dsgm.agent.sink.http.minAlive=1 -Dsgm.agent.virgo.address=10.24.216.198:8999,10.223.182.52:8999,10.25.217.95:8999 -Dsgm.agent.zone=m6 -Dsgm.agent.group=m6-discount -Dsgm.agent.tenant=jdjr -Dsgm.deployment.platform=jdt-jdos --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED --add-opens=java.management/sun.management=ALL-UNNAMED --add-opens=java.management/java.lang.management=ALL-UNNAMED -DJDOS_DATACENTER=JXQ -Ddeploy.app.name=jdos_kj_market-reduction-center -Ddeploy.app.id=30005051 -Ddeploy.instance.id=0 -Ddeploy.instance.name=server -Djava.awt.headless=true -Djava.net.preferIPv4Stack=true -Djava.util.Arrays.useLegacyMergeSort=true -Dog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dlog4j2.AsyncQueueFullPolicy=Discard -Xmx12g -Xms12g -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:MaxDirectMemorySize=2048m -XX:+UseZGC -XX:ZAllocationSpikeTolerance=3 -XX:ParallelGCThreads=8 -XX:CICompilerCount=3 -XX:-RestrictContended -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/export/logs --add-opens=java.base/sun.net.util=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.math=ALL-UNNAMED --add-opens=java.base/sun.security.action=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED -Dloader.path=/export/package/jdos_kj_market-reduction-center/conf

系统验证

系统可以成功启动后，就可以进行功能验证。有几个验证重点与方法：

首先可以通过单元测试快速进行系统全面回归，避免出现 JDK API、中间件 API 变更导致的业务异常
部署到测试环境，验证各个中间件是否正常，如 DUCC 开关下发，MQ 收发，JSF 接口调用等等，系统中所有用到的中间件都需要一一验证
然后可以开始进行核心业务的验证，这时候可以利用测试同学的测试自动化能力加人工补充场景，快速进行核心业务回归。其中研发需要观察系统被调用时的所有异常日志，包括警告，明确每条日志产生的原因
验证完成后，可以部署到联调环境，利用外部同事联调时的请求进一步进行验证
充分在测试环境观察后，部署至预发环境，利用外部同事联调时的请求进一步进行验证，并进行常态化压测，验证优化效果与瓶颈
经过预发长时间验证，没有问题后，部署一台生产，通过回放生产流量进一步进行验证
回放流量无异常后，开始承接生产流量，按接口开量，进行若干周的观察
逐步切量，直到全量上线

GC 调优

ZGC 介绍

如图所示，ZGC 的定位是一个最大暂停时间小于 1ms，且能够处理大小从 8MB 到 16TB 的堆，并且易于调优的垃圾回收器。ZGC 只有三个 STW 阶段，具体流程网上有大量类似文章，这里不做详细介绍。

优化方向

目前我们的应用日常使用 G1 约 30ms 的 GC 停顿时间，不到 1 分钟就会触发一次，大促时频率更高，暂停时间更长，导致接口性能波动较大。随着业务发展，为了优化系统我们大量应用了本地缓存，导致存活对象较多。ZGC 暂停时间不随堆、活动集或根集大小而增加，且极低的 GC 时间正是我们需要的特性，因此决定使用 ZGC。

ZGC 作为一个现代化 GC，没有必要做过多的优化，默认配置已经可以解决 99.9% 的场景。但是我们的应用会承接大促流量，根据观察，瞬时流量激增时 GC 时机较晚，因此应对突发流量是我们 ZGC 调优的一个目标，其他属性不做任何调整。

优化措施

ZGC 的一个优化措施就是足够大的堆，一般来说，给 ZGC 的内存越多越好，但我们也没必要浪费，通过压测观察 GC 日志，取得一个合适的值即可。我们只要保证：

堆可以容纳应用程序产生的实时垃圾
堆中有足够的空间，以便在 GC 运行时，为新的垃圾分配提供空间

因此，我们将机器升级成 8C 16G 配置，观察 GC 日志根据应用情况调整内存占用配置，最终设定为 -Xmx12g -Xms12g -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:MaxDirectMemorySize=2048m，提升 ZGC 的效果。

剩下的其他优化措施则视情况而定，可以调整触发 GC 的时机，也可以改为基于固定时间间隔触发 GC。

我们略微提升了触发时机，-XX:ZAllocationSpikeTolerance=3（默认为 2）应对突发流量。

CICompilerCount ParallelGCThreads 一个是提升 JIT 编译速度，一个是垃圾收集器并行阶段使用的线程数，根据实际情况略微增加，牺牲一点点 CPU 使用率，提升下效率。

另外还可以开启 Large Pages 进一步提升性能。这一步我们没有做，因为现在部署方式为一台物理机 Docker 混部署。开启需要修改内核，影响宿主机的其他镜像。

总结

至此，调优完成，目前我们已在线上跑了一个多月，每周都有三次常态化压测，一切正常。

以上升级心得分享给大家，希望对各位有所帮助。

Java CompletableFuture 异步超时实现探索

Mon, 22 Jan 2024 21:11:00 +0800

前言

JDK 8 是一次重大的版本升级，新增了非常多的特性，其中之一便是 CompletableFuture。自此从 JDK 层面真正意义上的支持了基于事件的异步编程范式，弥补了 Future 的缺陷。

在我们的日常优化中，最常用手段便是多线程并行执行。这时候就会涉及到 CompletableFuture 的使用。

常见使用方式

下面举例一个常见场景。

假如我们有两个 RPC 远程调用服务，我们需要获取两个 RPC 的结果后，再进行后续逻辑处理。

public static void main(String[] args) {
    // 任务 A，耗时 2 秒
    int resultA = compute(1);
    // 任务 B，耗时 2 秒
    int resultB = compute(2);

    // 后续业务逻辑处理
    System.out.println(resultA + resultB);
}

可以预估到，串行执行最少耗时 4 秒，并且 B 任务并不依赖 A 任务结果。

对于这种场景，我们通常会选择并行的方式优化，Demo 代码如下：

public static void main(String[] args) {
    // 仅简单举例，在生产代码中可别这么写！

    // 统计耗时的函数
    time(() -> {
        CompletableFuture<Integer> result = Stream.of(1, 2)
                                                  // 创建异步任务
                                                  .map(x -> CompletableFuture.supplyAsync(() -> compute(x), executor))
                                                  // 聚合
                                                  .reduce(CompletableFuture.completedFuture(0), (x, y) -> x.thenCombineAsync(y, Integer::sum, executor));

        // 等待结果
        try {
            System.out.println("结果：" + result.get());
        } catch (ExecutionException | InterruptedException e) {
            System.err.println("任务执行异常");
        }
    });
}

输出：

[async-1]: 任务执行开始：1
[async-2]: 任务执行开始：2
[async-1]: 任务执行完成：1
[async-2]: 任务执行完成：2
结果：3
耗时：2 秒

可以看到耗时变成了 2 秒。

存在的问题

分析

看上去 CompletableFuture 现有功能可以满足我们诉求。但当我们引入一些现实常见情况时，一些潜在的不足便暴露出来了。

compute(x) 如果是一个根据入参查询用户某类型优惠券列表的任务，我们需要查询两种优惠券并组合在一起返回给上游。假如上游要求我们 2 秒内处理完毕并返回结果，但 compute(x) 耗时却在 0.5 秒 ~ 无穷大波动。这时候我们就需要把耗时过长的 compute(x) 任务结果放弃，仅处理在指定时间内完成的任务，尽可能保证服务可用。

那么以上代码的耗时由耗时最长的服务决定，无法满足现有诉求。通常我们会使用 get(long timeout, TimeUnit unit) 来指定获取结果的超时时间，并且我们会给 compute(x) 设置一个超时时间，达到后自动抛异常来中断任务。

public static void main(String[] args) {
    // 仅简单举例，在生产代码中可别这么写！

    // 统计耗时的函数
    time(() -> {
        List<CompletableFuture<Integer>> result = Stream.of(1, 2)
                                                        // 创建异步任务，compute(x) 超时抛出异常
                                                        .map(x -> CompletableFuture.supplyAsync(() -> compute(x), executor))
                                                        .toList();

        // 等待结果
        int res = 0;
        for (CompletableFuture<Integer> future : result) {
            try {
                res += future.get(2, SECONDS);
            } catch (ExecutionException | InterruptedException | TimeoutException e) {
                System.err.println("任务执行异常或超时");
            }
        }

        System.out.println("结果：" + res);
    });
}

输出：

[async-2]: 任务执行开始：2
[async-1]: 任务执行开始：1
[async-1]: 任务执行完成：1
任务执行异常或超时
结果：1
耗时：2 秒

可以看到，只要我们能够给 compute(x) 设置一个超时时间将任务中断，结合 get、getNow 等获取结果的方式，就可以很好地管理整体耗时。

那么问题也就转变成了，如何给任务设置异步超时时间呢？

现有做法

当异步任务是一个 RPC 请求时，我们可以设置一个 JSF（类似 Dubbo 的中间件）超时，以达到异步超时效果。

当请求是一个 R2M（类似 Jedis 的中间件）请求时，我们也可以控制 R2M 连接的最大超时时间来达到效果。

这么看好像我们都是在依赖三方中间件的能力来管理任务超时时间？那么就存在一个问题，中间件超时控制能力有限，如果异步任务是中间件 IO 操作 + 本地计算操作怎么办？

用 JSF 超时举一个具体的例子，反编译 JSF 的获取结果代码如下：

public V get(long timeout, TimeUnit unit) throws InterruptedException {
    // 配置的超时时间
    timeout = unit.toMillis(timeout);
    // 剩余等待时间
    long remaintime = timeout - (this.sentTime - this.genTime);
    if (remaintime <= 0L) {
        if (this.isDone()) {
            // 反序列化获取结果
            return this.getNow();
        }
    } else if (this.await(remaintime, TimeUnit.MILLISECONDS)) {
        // 等待时间内任务完成，反序列化获取结果
        return this.getNow();
    }

    this.setDoneTime();
    // 超时抛出异常
    throw this.clientTimeoutException(false);
}

当这个任务刚好卡在超时边缘完成时，这个任务的耗时时间就变成了超时时间 + 获取结果时间。而获取结果（反序列化）作为纯本地计算操作，耗时长短受 CPU 影响较大。

某些 CPU 使用率高的情况下，就会出现异步任务没能触发抛出异常中断，导致我们无法准确控制超时时间。对上游来说，本次请求全部失败。

解决方式

JDK 9

这类问题非常常见，如大促场景，服务器 CPU 瞬间升高就会出现以上问题。

那么如何解决呢？其实 JDK 的开发大佬们早有研究。在 JDK 9，CompletableFuture 正式提供了 orTimeout、completeTimeout 方法，来准确实现异步超时控制。

public CompletableFuture<T> orTimeout(long timeout, TimeUnit unit) {
    if (unit == null)
        throw new NullPointerException();
    if (result == null)
        whenComplete(new Canceller(Delayer.delay(new Timeout(this), timeout, unit)));
    return this;
}

JDK 9 orTimeout 其实现原理是通过一个定时任务，在给定时间之后抛出异常。如果任务在指定时间内完成，则取消抛异常的操作。

以上代码我们按执行顺序来看下：

首先执行 new Timeout(this)。

static final class Timeout implements Runnable {
    final CompletableFuture f;
    Timeout(CompletableFuture f) { this.f = f; }
    public void run() {
        if (f != null && !f.isDone())
            // 抛出超时异常
            f.completeExceptionally(new TimeoutException());
    }
}

通过源码可以看到，Timeout 是一个实现 Runnable 的类，run() 方法负责给传入的异步任务通过 completeExceptionally CAS 赋值异常，将任务标记为异常完成。

那么谁来触发这个 run() 方法呢？我们看下 Delayer 的实现。

static final class Delayer {
    static ScheduledFuture delay(Runnable command, long delay,
                                    TimeUnit unit) {
        // 到时间触发 command 任务
        return delayer.schedule(command, delay, unit);
    }

    static final class DaemonThreadFactory implements ThreadFactory {
        public Thread newThread(Runnable r) {
            Thread t = new Thread(r);
            t.setDaemon(true);
            t.setName("CompletableFutureDelayScheduler");
            return t;
        }
    }

    static final ScheduledThreadPoolExecutor delayer;
    static {
        (delayer = new ScheduledThreadPoolExecutor(
            1, new DaemonThreadFactory())).
            setRemoveOnCancelPolicy(true);
    }
}

Delayer 其实就是一个单例定时调度器，Delayer.delay(new Timeout(this), timeout, unit) 通过 ScheduledThreadPoolExecutor 实现指定时间后触发 Timeout 的 run() 方法。

到这里就已经实现了超时抛出异常的操作。但当任务完成时，就没必要触发 Timeout 了。因此我们还需要实现一个取消逻辑。

static final class Canceller implements BiConsumer<Object, Throwable> {
    final Future f;
    Canceller(Future f) { this.f = f; }
    public void accept(Object ignore, Throwable ex) {
        if (ex == null && f != null && !f.isDone())
        // 3 未触发抛异常任务则取消
            f.cancel(false);
    }
}

当任务执行完成，或者任务执行异常时，我们也就没必要抛出超时异常了。因此我们可以把 delayer.schedule(command, delay, unit) 返回的定时超时任务取消，不再触发 Timeout。当我们的异步任务完成，并且定时超时任务未完成的时候，就是我们取消的时机。因此我们可以通过 whenComplete(BiConsumer action) 来完成。

Canceller 就是一个 BiConsumer 的实现。其持有了 delayer.schedule(command, delay, unit) 返回的定时超时任务，accept(Object ignore, Throwable ex) 实现了定时超时任务未完成后，执行 cancel(boolean mayInterruptIfRunning) 取消任务的操作。

JDK 8

如果我们使用的是 JDK 9 或以上，我们可以直接用 JDK 的实现来完成异步超时操作。那么 JDK 8 怎么办呢？

其实我们也可以根据上述逻辑简单实现一个工具类来辅助。

以下是我们营销自己的工具类以及用法，贴出来给大家作为参考，大家也可以自己写的更优雅一些~

调用方式：

CompletableFutureExpandUtils.orTimeout(异步任务, 超时时间, 时间单位);

工具类源码：

package com.jd.jr.market.reduction.util;

import com.jdpay.market.common.exception.UncheckedException;

import java.util.concurrent.*;
import java.util.function.BiConsumer;

/**
 * CompletableFuture 扩展工具
 *
 * @author zhangtianci7
 */
public class CompletableFutureExpandUtils {

    /**
     * 如果在给定超时之前未完成，则异常完成此 CompletableFuture 并抛出 {@link TimeoutException} 。
     *
     * @param timeout 在出现 TimeoutException 异常完成之前等待多长时间，以 {@code unit} 为单位
     * @param unit    一个 {@link TimeUnit}，结合 {@code timeout} 参数，表示给定粒度单位的持续时间
     * @return 入参的 CompletableFuture
     */
    public static <T> CompletableFuture<T> orTimeout(CompletableFuture<T> future, long timeout, TimeUnit unit) {
        if (null == unit) {
            throw new UncheckedException("时间的给定粒度不能为空");
        }
        if (null == future) {
            throw new UncheckedException("异步任务不能为空");
        }
        if (future.isDone()) {
            return future;
        }

        return future.whenComplete(new Canceller(Delayer.delay(new Timeout(future), timeout, unit)));
    }

    /**
     * 超时时异常完成的操作
     */
    static final class Timeout implements Runnable {
        final CompletableFuture future;

        Timeout(CompletableFuture future) {
            this.future = future;
        }

        public void run() {
            if (null != future && !future.isDone()) {
                future.completeExceptionally(new TimeoutException());
            }
        }
    }

    /**
     * 取消不需要的超时的操作
     */
    static final class Canceller implements BiConsumer<Object, Throwable> {
        final Future future;

        Canceller(Future future) {
            this.future = future;
        }

        public void accept(Object ignore, Throwable ex) {
            if (null == ex && null != future && !future.isDone()) {
                future.cancel(false);
            }
        }
    }

    /**
     * 单例延迟调度器，仅用于启动和取消任务，一个线程就足够
     */
    static final class Delayer {
        static ScheduledFuture delay(Runnable command, long delay, TimeUnit unit) {
            return delayer.schedule(command, delay, unit);
        }

        static final class DaemonThreadFactory implements ThreadFactory {
            public Thread newThread(Runnable r) {
                Thread t = new Thread(r);
                t.setDaemon(true);
                t.setName("CompletableFutureExpandUtilsDelayScheduler");
                return t;
            }
        }

        static final ScheduledThreadPoolExecutor delayer;

        static {
            delayer = new ScheduledThreadPoolExecutor(1, new DaemonThreadFactory());
            delayer.setRemoveOnCancelPolicy(true);
        }
    }
}

参考资料

JEP 266: JDK 9 并发包更新提案

大学毕业租房攻略

Sun, 26 Sep 2021 22:34:00 +0800

前言

来北京快要一年了，现在回想起这一年来还是有点感慨。其中比较遗憾的是房子租的不太满意，踩了不少坑。

最近决定房子到期后不再续租，租一个新的房子。正好整理一下租房时需要注意的坑。

租房注意事项

合租室友

为什么这一条单独放在第一个说？因为一个不好的室友，再好的房子也会让你痛苦不堪。

一定要确认以下内容：

室友不是无业游民；
室友作息时间基本和你一致；
室友卫生情况你能不能接受（可以观察她用的卫生间、厨房及其房间的卫生情况判断）；
性别最好是同性；

这里说一下第四条，生活习惯、生理特性的不同会让上班本来就很疲惫的你雪上加霜。

女生头发较长，掉在地上很明显。那就意味着想和男生保持一样的整洁度，女生要更勤快一点（男的正在秃顶过程中除外）。卫生间女生需要摆一个垃圾桶，男生不用。女生喜欢在房间弄些香香的东西，男生习惯保持原味。

费用

房租

首先当然要考虑清楚自己能有多少预算用来租房子。

我认为，房租占工资的 20% ~ 35% 左右都可接受。比如刚毕业的大学生来北漂，假如一个月 6000 的实习工资，那可以考虑租 1200 ~ 2100 的房子。房租高过这个范围那就有点超过你的承受能力了，要慎重考虑。要给自己留下吃饭、生病、同事聚会、出去玩耍和买买买等等的预算，小心变成一个月光族。

生活费用

除房租外，还要考虑水、电、网、燃气、暖气和物业费。

其中常见的是水、电、网和燃气自付，暖气和物业费房东出。要注意商水商电可比你想象的贵。尤其是夏天开空调，舍友是个无业游民并且半夜不睡觉，会比民水民电贵 3 ~ 4 倍。

中介费

这个费用的坑就比较多了，大多数中介是收一个月房租作为中介费。

万万不可在签合同前交出任何看房、中介等等各种费用。万一在看房途中觉得房租不好，钱大概率是要不回来的。

建议在来北京前，可以问问公司同事房源、转租信息。这是免中介费的好方法。

设施

看房时，讲究就比较多了，要留意的地方也比较多。

房屋结构

需确认是否朝阳，阳台是否方便晒洗衣服，隔音情况如何，通风情况如何，插座有几个，插座位置是否合适。

窗户朝北冬天较冷，朝西夏天太晒，朝东下午太暗，结合上班时间考虑，需要注意自己能接受哪种。

电器

是否有空调、洗衣机、冰箱等必备电器，是否有宽带，要检查上述电器及网络能否正常使用。

屋内设施

衣柜，桌椅，窗户，暖气片，沙发，床垫，床板，地砖，门是否正常和老旧。

要重点留意卧室窗户是否漏风，不严实会导致冬冷夏热，空调会更费电。

洗漱间

卫浴太阳能、热水 24 h，检查是否老旧，淋浴头和水龙头等等会不会漏水，地漏是否可以正常排水，马桶水压、流速和流量足不足。

其他

在室内的手机信号如何，宽带网速快不快，稳定不稳定，如果是顶楼房顶会不会漏水，5 楼及以上的楼层有没有电梯。

周边环境

小区周围有没有地铁、公交、饭店、药店、商场超市、菜市场、公园等等。

看房

再次注意，没有签合同不交任何费用，不要隔断间。

最好看两次房子，白天看采光和交通，晚上看隔音、照明和小区安全性。

合同

注意，签合同是最后一步，要确保上面得内容全部一一确认自己可以接受。

合同一定要仔细看，别不好意思。

下面事项请考虑周全：

合约一年还是半年，整租还是合租；
合同上写明房东、二房东、承租人的姓名和身份证号码；
要写明房屋的地址，面积，房产证编号（签约时务必要求出示房产证）；
要查看房东房产证，身份证复印件，二房东身份证复印件，与房东签订的委托书或租房合同复印件和营业执照复印件并留存；（要确认是否允许二次出租转租分租）
签约后再交钱，并要开收据，允许以后用公积金租房；
清点好家具电器板凳数量，哪里损坏，新旧程度等，并签字；
写明水电天然气数字，避免争议；
电器非人为故障谁负责修，明确后续老化等问题的责任与维修期限；
提前终止合同如何赔偿；
押金退还日期，扣除事项；
是否可以贴墙纸，钉钉子；
所有姓名全部都为真名，如果房产证上有多人，那么签约时尽量要求全部到场，如不能到场，需要房产所有人出示授权书；
审核房产证明，并要求房东身份证复印件一份供租客留底。基于公平，租客也可给房东留底身份证复印件一份。因为缺少了中介环节，所以一定要房东将身份证复印件留下来，以防万一。除上述之外，无论是哪种签约方式，还要注意两个共同的问题：不要向没有房东转租许可的二房东租房。没签约之前，绝不能交房租。交押金之后，一定要房东开具收据。
谈租房条件的时候，别忘了说清楚电器非人为故障由谁负责维修，一般房东都会答应负责维修费，谈好请写进合同。明确后续老化等问题的责任，必要时录像、录音。

最后

以上内容其实难以一一做到，能做到一大半就可以租一个满意的房子了。

普通人没那么坏，房子的优缺点不会特意瞒着你，欺骗你。只是自己要留一个心眼，我们不去害人，但也要保证自己的利益。

SQL 语句执行缓慢原因分析

Sun, 05 Sep 2021 16:17:00 +0800

概述

SQL 查询性能优化是软件开发的核心技能之一。本文系统性地分析了 SQL 执行缓慢的各种原因，并提供了相应的诊断方法和解决方案。

分类讨论

SQL 执行缓慢可分为两种基本情况：

偶发性缓慢：大多数情况正常，偶尔出现性能问题
持续性缓慢：在数据量不变的情况下，一直执行缓慢

针对这两种情况，我们来分析下可能是哪些原因导致的。

针对偶尔很慢的情况

一条 SQL 大多数情况正常，偶尔才能出现很慢的情况，我觉得这条 SQL 语句的书写本身是没什么问题，而是其他原因导致。

数据库在刷新脏页

当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在缓冲池中把对应字段的数据更新，但是更新之后，这些更新的字段并不会马上同步持久化到磁盘中去，而是把这些更新的记录写入到 redo log 中去。等到空闲的时候，在通过 redo log 里的记录把最新的数据同步到磁盘中去。

不过，redo log 里的容量是有限的。如果数据库一直很忙，更新又很频繁，这个时候 redo log 很快就会被写满，就没办法等到空闲的时候再把数据同步到磁盘，只能暂停其他操作，全身心来把数据同步到磁盘中去。而这个时候，就会导致我们平时正常的 SQL 语句突然执行的很慢。

机制说明

数据库使用缓冲池（Buffer Pool）在内存中缓存数据页
数据修改先在内存中完成，异步写入磁盘（Write-Ahead Logging）
Redo Log 确保事务持久性，但容量有限

性能影响场景

Redo Log 写满时，必须强制刷脏页到磁盘
缓冲池空间不足，需要淘汰脏页
数据库正常关闭或检查点（Checkpoint）触发

监控与诊断

-- 查看InnoDB状态（包含缓冲池信息）
SHOW ENGINE INNODB STATUS;

-- 监控脏页比例
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

锁竞争问题

这个就比较容易想到了。我们要执行的这条语句，刚好这条语句涉及到的表，别人在用，并且加锁。或者表没有加锁，但要使用到的某个一行被加锁。我们拿不到锁，只能慢慢等待别人释放锁。

如果要判断是否真的在等待锁，我们可以用 show processlist 这个命令来查看当前的状态。

锁类型分析

锁类型	范围	影响	诊断方法
表级锁	整个表	高并发下严重影响性能	`SHOW PROCESSLIST`
行级锁	单行记录	影响特定数据操作	`SHOW ENGINE INNODB STATUS`
元数据锁	表结构变更	DDL 操作阻塞查询	`performance_schema.metadata_locks`
间隙锁	索引范围	防止幻读，可能过度锁定	分析事务隔离级别

监控与诊断

-- 查看当前连接和锁状态
SHOW PROCESSLIST;

-- 查看InnoDB锁信息（MySQL 5.7+）
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;

-- 查看等待锁的线程
SELECT * FROM sys.innodb_lock_waits;

其他偶发因素

还有一些其他原因和数据库内部机制，以及所在的的网络、物理机有关，本文不做详细讨论。

系统资源瓶颈

CPU 瞬时峰值
内存交换 (SWAP) 发生
磁盘 I/O 瓶颈
网络波动

数据库内部机制

自适应哈希索引 (Adaptive Hash Index) 重建
变更缓冲区 (Change Buffer) 合并
统计信息自动更新

针对一直都这么慢的情况

下来我们来访分析下第二种情况，我觉得第二种情况的分析才是最重要的。

如果在数据量一样大的情况下，这条 SQL 语句每次都执行的这么慢，那就就要好好考虑下你的 SQL 书写了，下面我们来分析下哪些原因会导致我们的 SQL 语句执行的很不理想。

我们先来假设我们有一个表，表里有下面两个字段,分别是主键 id，和两个普通字段 c 和 d。

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  `d` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

没用到索引

没有用上索引，我觉得这个原因是很多人都能想到的，例如你要查询这条语句

select * from t where 100 < c and c < 100000;

字段没有索引

刚好你的 c 字段上没有索引，那么抱歉，只能走全表扫描了，你就体验不会索引带来的乐趣了，所以，这回导致这条查询语句很慢。

解决方案：

-- 分析查询模式后添加索引
ALTER TABLE t ADD INDEX idx_c (c);
ALTER TABLE t ADD INDEX idx_c_d (c, d); -- 复合索引

没有用索引

好吧，这个时候你给 c 这个字段加上了索引，然后又查询了一条语句

select * from t where c - 1 = 1000;

我想问这样在查询的时候会用索引查询吗？

答是不会，如果我们在字段的左边做了运算，那么很抱歉，在查询的时候，就不会用上索引了，所以要注意这种字段上有索引，但由于自己的疏忽，导致系统没有使用索引的情况。

正确的查询应该如下

select * from t where c = 1000 + 1;

有人可能会说，右边有运算就能用上索引？难道数据库就不会自动帮我们优化一下，自动把 c - 1=1000 自动转换为 c = 1000+1。

不好意思，确实不会帮你，所以，你要注意了。

如果我们在查询的时候，对字段进行了函数操作，也是会导致没有用上索引的，例如：

select * from t where pow(c) = 1000;

这里我只是做一个例子，实际上可能并没有 pow(c) 这个函数。其实这个和上面在左边做运算也是很类似的。

所以呢，一条语句执行都很慢的时候，可能是该语句没有用上索引了，不过具体是啥原因导致没有用上索引的呢，你就要会分析了，我上面列举的三个原因，应该是出现的比较多的。

常见索引失效情况

失效模式	示例	解决方案
左侧运算	`WHERE c - 1 = 1000`	重写为 `WHERE c = 1000 + 1`
函数操作	`WHERE DATE(create_time) = '2023-01-01'`	使用范围查询 `WHERE create_time >= '2023-01-01' AND create_time < '2023-01-02'`
隐式类型转换	`WHERE string_col = 123`	保持类型一致 `WHERE string_col = '123'`
OR 条件不当	`WHERE c = 100 OR d = 200`	使用 UNION 或分别索引
模糊查询前缀	`WHERE name LIKE '%abc'`	避免前导通配符

索引设计原则

高选择性字段优先建索引
考虑复合索引的字段顺序
避免过度索引（写操作开销）
覆盖索引减少回表

数据库选错索引

我们在进行查询操作的时候，例如：

select * from t where 100 < c and c < 100000;

我们知道，主键索引和非主键索引是有区别的，主键索引存放的值是整行字段的数据，而非主键索引上存放的值不是整行字段的数据，而且存放主键字段的值。

也就是说，我们如果走 c 这个字段的索引的话，最后会查询到对应主键的值，然后，再根据主键的值走主键索引，查询到整行数据返回。

就算你在 c 字段上有索引，系统也并不一定会走 c 这个字段上的索引，而是有可能会直接扫描扫描全表，找出所有符合 100 < c and c < 100000 的数据。

系统在执行这条语句的时候，会进行预测：究竟是走 c 索引扫描的行数少，还是直接扫描全表扫描的行数少呢？显然，扫描行数越少当然越好了，因为扫描行数越少，意味着 I/O 操作的次数越少。

如果是扫描全表的话，那么扫描的次数就是这个表的总行数了，假设为 n；而如果走索引 c 的话，我们通过索引 c 找到主键之后，还得再通过主键索引来找我们整行的数据，也就是说，需要走两次索引。而且，我们也不知道符合 100 c < and c < 10000 这个条件的数据有多少行，万一这个表是全部数据都符合呢？这个时候意味着，走 c 索引不仅扫描的行数是 n，同时还得每行数据走两次索引。

所以系统是有可能走全表扫描而不走索引的。那系统是怎么判断呢？

索引判断原则

判断来源于系统的预测，也就是说，如果要走 c 字段索引的话，系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多，它可能就不走索引而直接扫描全表了。

系统是通过索引的区分度来判断的，一个索引上不同的值越多，意味着出现相同数值的索引越少，意味着索引的区分度越高。我们也把区分度称之为基数，即区分度越高，基数越大。所以呢，基数越大，意味着符合 100 < c and c < 10000 这个条件的行数越少。

所以呢，一个索引的基数越大，意味着走索引查询越有优势。

那么问题来了，怎么知道这个索引的基数呢？

系统当然是不会遍历全部来获得一个索引的基数的，代价太大了，索引系统是通过遍历部分数据，也就是通过采样的方式，来预测索引的基数的。

扯了这么多，重点的来了，居然是采样，那就有可能出现失误的情况，也就是说，c 这个索引的基数实际上是很大的，但是采样的时候，却很不幸，把这个索引的基数预测成很小。例如你采样的那一部分数据刚好基数很小，然后就误以为索引的基数很小。然后就呵呵，系统就不走 c 索引了，直接走全部扫描。

所以呢，说了这么多，得出结论：由于统计的失误，导致系统没有走索引，而是走了全表扫描，而这，也是导致我们 SQL 语句执行的很慢的原因。

这里我声明一下，系统判断是否走索引，扫描行数的预测其实只是原因之一，这条查询语句是否需要使用使用临时表、是否需要排序等也是会影响系统的选择的。

影响因素：

索引选择性
预计需要回表的次数
临时表、排序开销
历史执行统计（MySQL 8.0+）

解决方案

不过呢，我们有时候也可以通过强制走索引的方式来查询，例如：

SELECT * FROM t FORCE INDEX(idx_c) WHERE c > 100 AND c < 100000;

我们也可以通过

SHOW INDEX FROM t;

来查询索引的基数和实际是否符合，如果和实际很不符合的话，我们可以重新来统计索引的基数，可以用这条命令

ANALYZE TABLE t;

来重新统计分析。

既然会预测错索引的基数，这也意味着，当我们的查询语句有多个索引的时候，系统有可能也会选错索引，这也可能是 SQL 执行的很慢的一个原因。

系统化诊断流程

上述问题应该怎么发现呢？我列举了一些常用的手段。

性能分析工具

EXPLAIN

通过查看执行计划，提前避免问题。

EXPLAIN FORMAT=JSON SELECT * FROM t WHERE c > 100;

关键指标关注：

type：访问类型（const, ref, range, index, ALL）
key：实际使用的索引
rows：预估扫描行数
Extra：额外信息（Using where, Using temporary, Using filesort）

性能监控（Performance Schema）

-- 开启语句监控
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' 
WHERE NAME LIKE 'events_statements%';

-- 查看慢查询统计
SELECT * FROM performance_schema.events_statements_summary_by_digest 
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

慢查询日志分析

# my.cnf 配置
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1

高级优化策略

架构层面优化

读写分离
分库分表
缓存策略（Redis, Memcached）
数据归档和历史表

数据库参数调优

# InnoDB缓冲池（通常设为物理内存的70-80%）
innodb_buffer_pool_size = 16G

# 日志文件大小
innodb_log_file_size = 2G

# 并发连接控制
max_connections = 500
thread_cache_size = 50

应用层优化

连接池配置
批量操作减少网络往返
预处理语句避免重复解析
适当的数据缓存

总结

SQL 性能优化是一个系统性的工程，需要从多个维度进行分析和解决。本文提供的分析框架和优化策略覆盖了从基础到高级的各个层面，可以作为日常性能优化的参考指南。

核心要点：

建立系统化的诊断流程
索引是最高效的优化手段
统计信息的准确性至关重要
监控和预防优于事后补救
优化需要综合考虑成本和收益

建议定期进行数据库健康检查，建立性能基线，以便快速识别和解决性能问题。

月度开销记录方式分享

Wed, 01 Sep 2021 19:23:00 +0800

前言

简介

现在消费主义横行，随便刷刷新闻，看看短视频，就很容易产生消费冲动。为了避免开销过大，成为月光族，做好预算和养成记账习惯可以保证在不降低生活幸福感的前提下，实现理性消费，提高生活品质。

下面分享一下我大学和现在用的记账模板。

大学记账模板

模板介绍

主要使用学期费用这一列按学期来做预算，如果这个月有其他无法预计的支出则记录在每月支出中。

每月收入则是父母给的生活费以及其他收入。

根据以上数据生成一个简单的图表，主要看盈余来考虑下个月大概还能花多少钱。

我这个模板还算好用吧，按学期做规划比较方便。

毕业后记账模板

模板介绍

因为毕业后消费较为复杂，所以做了自定义类别。

这个模板主要是根据大学模板的缺点改良来的。

汇总这里没做可视化数据表，感觉没什么意义。只留下了我比较关心的几个数字，比如本月存款和存款增长百分比。

其他数据和可视化数据表等我认为需要用到的时候我再加上吧。目前我认为显示这些就足够了。

目前在用的记账软件

==请注意，我并不推荐任何记账软件。==

国家对个人信息这一块的监管和法律基本等于空白，因此软件方早晚有一天会拿你的信息通过各种途径去盈利，去做用户画像、个性化广告等等。

但是现在移动支付入口基本掌握在微信和支付宝手中，其实你的消费习惯、能力等信息早已经被泄露分析了。那么这类软件是否值得信赖，要不要用，如何使用，要慎重考虑。

软件介绍

之所以没有继续使用 Excel，是因为工作一天回到家，实在是不想开电脑进行记录了。移动端的 Excel 操作体验又差，因此需要一个移动端的记账软件。

现在市面上的记账软件或多或少都有社区、金融理财等和记账不相关的功能。为了商业化，可以理解，但是不能接受。其实我们只需要一个专注于记账功能的软件就够了。

其实我也有想过自己开发一个 Web 端的通用记账管理系统，但因为各种各样的原因（995、懒），实在是腾不出手来，因此直接买了一个记账软件——记账鸭。

这款软件也可以免费使用，缺点是账本数量有限制，所以我干脆买了一个终身会员（当时是 60 人民币左右入手的，最近涨价了，目前是 89 人民币）。

下载链接

各大安卓、苹果应用商店都有，自行下载。

最后

模板什么的其实能用就行，也不用太花哨。也没必要用某些记账软件来记录，做的再好能有 Excel 好吗？反而把自己的消费习惯暴露给软件厂商拿去牟利了。

记账一方面是需要一个可以用的模板，另一方面是要养成记账的习惯。不能今天想起来就记录一下，明天比较累就不记录了。还要记得对账，毕竟记录难免有遗漏或者错误。

理性消费，抵制消费主义，从记账做起 😎 。

如何贡献有价值的反馈

Sat, 03 Oct 2020 11:14:00 +0800

前言

我在工作中总会有如下对话：

某测试：“张，XX 功能报错了！” 我：“报什么错？” 某测试：“我用了下这个功能就报错了！” 我：“……（可能对方没理解我的意思？）有什么提示吗？怎么操作的？日志发来我瞧瞧。” 某测试：“我就是调用了一下就报错了，没看日志！张你研究下！” 我：……

这种对话不仅浪费时间，而且往往最后发现是对方没有仔细阅读文档导致的误用。无论是技术人员还是非技术人员，掌握如何提出有效反馈都能大大节约双方的时间。

当你决定反馈问题时（既然已经这么做了），肯定是希望问题能尽快解决。此时任何过激言语都无济于事——因为这可能是程序员的错误，也可能是你的错误。也许你有权对他们发火，但是如果你能提供有用的信息而非情绪化表达，问题往往会更快得到解决。

基于这些经验，我整理了以下建议，希望能帮助大家提出更有价值的反馈。

提问前

遇到问题时，心里一定很着急，可以理解。但是在决定向开源社区或开发人员提交问题前，建议先尝试以下步骤：

阅读文档

查阅相关功能的官方文档，利用搜索功能查找问题关键词，很多时候能快速找到解决方案。

搜索引擎

90% 你遇到的问题，很可能别人也遇到过。通过 Google、StackOverflow 等技术社区搜索（建议避开 CSDN 等低质量站点），往往能快速定位解决方法。

永远记住，地球上的你并不孤单，包括你遇到的问题。

问问身边的人

如果你身边的人也曾用过同一个功能，可以礼貌地请教。善意的技术探讨很少有人会拒绝。

如果以上三步都无法解决问题，就不要犹豫，立马向开源社区或开发人员提交问题就好。

提问时

提问有很多种，比如你认识作者，直接面对面请教就行。下面探讨的是如何通过互联网的方式来问问题。

平和对等的心态

提问时，不要把自己摆在顾客的位置，比如：

项目马上要上线了，请务必解决！

另外，也不要把自己摆在乞食者的位置，比如：

救命啊，这个功能我今天急用！

不论是在开源社区，还是公司部门之间，一切皆是朋友。无论对方是 Linux 内核的作者，还是新来的实习生，你们都是对等的。你的提问是在帮助完善软件。这种心态可以让你的问题赢得更多人的阅读和思考。

通过正确的途径提交

如果有专门的反馈邮箱或 Bug 管理系统，一定要使用这些指定渠道。

最不好的途径是：

QQ 、微信等群组。这些群组主要是用来休闲的。对开源项目来说，在这些地方提问，作者一般不会关注，效率非常低。
微博、Facebook 等社交网络。不少人在微博上通过 @ 或私信询问问题，这些我经常看不到。看到了，也不情愿回复。微博是扯淡、交流情感的地方，一般是写代码写累了，才去逛逛，很少会有在社交网络上回答技术问题的心情。

通过正确的途径提交问题，一般可以让你的问题得到及时准确的回复。

使用明确、有意义的标题

抱着平和对等的心态，找到合适的途径后，就得静下心来将遇到的问题写成文字。书写文字不是一件简单的事情，我们可以从遵循一些简单的规则开始。

首先是提问标题要简洁清晰，要言之有物。比如：

XX 功能出错，求大神指点

XX 功能在我的浏览器上运行不了，别人的可以

上面举例的标题很糟糕，光看标题作者无法知道发生了什么事。当开源社区的问题很多时，上面这类标题，经常会让作者直接忽视或将优先级降到很低。更妥当的标题是：

XX 功能提示 XXXXX（错误码）

XX 功能在 Chrome 69 无法使用

明确、有意义的标题，可以帮助作者确定问题具体是什么类型、预估需要多少时间解决、是否现在马上解决等。一个好的标题，也有利于社区知识的沉淀和后期搜索。标题有如一个人的颜面衣着，虽然不是关键，但在嘈杂的信息社区中，这很重要。

遵循良好的模板

如果社区提供了问题模板，一定要仔细看下。比如我的开源项目，当你创建一个问题时，会自动提供以下模板：

# 前言

请确认你已经做了下面这些事情，若 bug 还是未解决，那么请尽可详细地描述你的问题。

  - [ ] 我已经安装了最新版的 Hobby
  - [ ] 我已经搜索了已有的 Issues 列表中有关的信息
  - [ ] 我已经阅读了 Hobby 的 相关文档

# 描述错误



# 复现方式



# 预期行为



# 截图



# 系统版本和运行环境



# 其他

遵循这个模板去描述问题，经常能省很多事。作者一般也非常欢迎通过模板提交的问题。如果社区没有提供模板，也可以自己遵循以上模板来提交。

下面针对问题内容，具体说说一些需要注意的点。

注意语法和格式

虽然我们不是作家，但正确的语法、清晰的格式，可以让读者赏心悦目，也就更有心情帮你一起思考解决问题。

对于很多需要代码来描述的问题，要尤其注意格式，比如：

List<Category> children = categories.stream().filter(category -> Objects.equal(parentCategory.getId(), category.getParentId())).collect(Collectors.toList());

可读性不如：

List<Category> children = categories.stream()
            .filter(category -> Objects.equal(parentCategory.getId(), category.getParentId()))
            .collect(Collectors.toList());

良好的代码排版能让你的内容看起来很专业，大家也就更有意愿会去帮助你，否则糟糕的排版，经常带来的是提问之后的石沉大海。

描述事实而不是猜测

事实是指，依次进行了哪些操作、产生了怎样的结果。比如：

我在 XX 环境下，通过 XX 操作后，点击 XX，这时浏览器弹出 XX 错误提示。

上面是一段比较好的事实描述（更好的是把错误提示也截图上来），而不要像下面这样猜测：

XX 功能在 XX 环境下运行不正常，我怀疑是源码第 213 行有问题。

上面的描述，会让作者一头雾水、甚至很恼火。尽量避免猜测性描述，除非你能先描述事实，在事实描述清楚之后，再给出合理的猜测是欢迎的。

如果能提供可重现错误的在线可访问代码，那是最好不过。一旦你这么用心去做了，作者往往也会很用心地立马帮你解决。

描述目标而非过程

经常会有这种情况，提问者在脑袋里有个更高层次的目标，他们在自以为能达到目标的特定道路上卡住了，然后跑来问该怎么走。比如：

XX 应用如何手动指定 JDK 路径？

上面这个问题的背后，提问者实际上想解决的是如何通过手动指定 JDK 路径来实现单机安装多个 JDK 的问题。提问者选择了手动指定 JDK 的方式来实现，但这过程中遇到了问题，因此跑过来继续怎么走。然而，如果只是描述过程，往往会把作者也绕进去。

实际情况却是，提问者选择的路本身就是一条崎岖之路，对于要解决的问题，实际上有更好的方式。这种情况下，描述清楚目标，讲清楚要干什么非常重要。

在描述自己是怎么做之前，一定要先描述要做什么。提问题时，What 往往比 How 更重要。

要有具体场景

无论在开源社区，还是微博、知乎等平台上，有一种非常常见的问题：

如何优化 Java 代码性能？

如何使用 maven 进行模块化开发？

这类问题还有很多，每每遇到，只能笑笑，然后悄悄地忽略掉。因此这类问题很难回答，就如下面这些问题一样：

如何才能让生命有意义？

如何打败阿里？

这类提问者，一般比较浮躁，经常对问题本身也没有经过思考。踏实的提问者，不会让问题浮在空中无法回答，而会在具体场景中让问题落地：

我的项目有 20 多个 Java 模块，接下来还会急剧增加。目前遇到以下问题……（省略五百字）…… 请问如何维护？

正确描述问题

记录问题

当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。

演示问题

报告问题的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着你启动电脑、运行程序、如何进行操作以及程序对你的输入有何反应。

口述问题

“演示”是很好的办法，但是常常做不到。那我们应该尽可能确切地告诉程序员你做了些什么。如果是一个图形界面程序，告诉他们你按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们你输入了什么命令。你应该尽可能详细地提供所输入的命令和程序的反应。

把你能想到的所有的输入方式都告诉程序员，如果程序要读取一个文件，你可能需要把这个文件发给他们。如果程序需要通过网络与另一台电脑通讯，你或许不能把那台电脑复制过去，但至少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。

如果你给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为你没有给他们足够的信息，可能错误不是在每台计算机上都出现，你的系统可能和他们的在某些地方不一样。有时候程序的行为可能和你预想的不一样，这也许是误会，但是你会认为程序出错了，程序员却认为这是对的。

同样也要描述发生了什么。精确的描述你看到了什么。告诉他们为什么你觉得自己所看到的是错误的，最好再告诉他们，你认为自己应该看到什么。如果你只是说：“程序出错了”，那你很可能漏掉了非常重要的信息。

如果你看到了错误消息，一定要仔细、准确的告诉程序员，这确实很重要。在这种情况下，程序员只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。如果你没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无意义的，除非你把错误消息一块报上来。

特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。不要以为你看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉你错误的所在是一个最好的办法。

在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，保存好。

间歇性问题

“间歇性错误”着实让程序员发愁。相比之下，进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作，观察每一个细节。太多的问题在这种情况下不能解决，例如：程序每星期出一次错，或者偶然出一次错，或者在程序员面前从不出错。当然还有就是程序的截止日期到了，那肯定要出错。

大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的，有一些可能是别的程序在不恰当的时候修改某个重要文件造成的，还有一些可能发生在某一特定时间。

程序员想要了解任何与你发现的问题相关的事情。有可能的话你到另一台机器上试试，多试几次，两次，三次，看看问题是不是经常发生。如果问题出现在你进行了一系列操作之后，不是你想让它出现它就会出现，这就有可能是长时间的运行或处理大文件所导致的错误。程序崩溃的时候，你要尽可能的记住你都做了些什么，并且如果你看到任何图形,也别忘了提一下。你提供的任何事情都是有帮助的。即使只是概括性的描述。这虽然不能提供导致问题的直接线索，但是可能帮助程序员重现问题。

最重要的是：程序员想要确定他们正在处理的是一个真正的“间歇性错误”呢，还是一个在另一类特定的计算机上才出现的错误。他们想知道有关你计算机的许多细节，以便了解你的机器与他们的有什么不同。有许多细节都依仗特定的程序，但是有一件东西你一定要提供——版本号。程序的版本、操作系统的版本以及与问题有关的程序的版本。

仔细检查、确保准确

是人都会犯错误，特别是在如此快节奏的互联网环境下。好不容易把问题描述清楚时，不要急着立刻提交。在提交前，至少保证从头到尾再仔细阅读一遍，比如语法错误、错别字、标点符号、排版等等。做到这些，不光是尊重别人，也是尊重自己。

提问后

提交问题后，建议通过邮件等方式订阅回复。互联网上最有效的沟通方式是异步沟通，不要期待作者马上回复，也不要心烦意乱着急地等待。

尽可能补充信息

在接收到回复时，仔细阅读。最经常的情况是，社区回复的，经常不是你想要的。比如：

根据你的描述，问题无法重现。能否提供具体使用环境和重现步骤？

这时要淡定。仔细看看自己提交的问题描述是否足够清晰，如果有可补充的信息，尽量补充，以帮助作者能尽快定位问题。比如：

很抱歉，我前面有一步描述不正确，实际情况是我是在 Firefox 中运行的……

谦和淡定的交流，不光能帮助你解决问题，还有助于你结交更多朋友。

适当的总结

当问题终于解决时，建议对问题进行总结。可以编辑原帖，也可以通过博客等方式总结。你的总结，会让遇到同样问题的朋友们受益，并且对自己的技能也是一种提高。无论国内还是国外，有很多牛人之所以成为牛人，很大程度上都是因为有总结思考的好习惯。

不要忘记感谢

最后，记得感谢。很多开源软件的作者，都是利用业余时间在创作代码。你的感谢，会让开源社区充满爱与力量。

学科竞赛训练管理系统设计与实现

Mon, 01 Jun 2020 14:20:00 +0800

前言

学科竞赛训练管理系统的前端使用 React 创建组件，使用 Nginx 解决跨域问题；后端使用 Spring Boot 搭建项目，使用 Spring Security 保证安全，使用 Spring Data JPA 访问 PostgreSQL，使用 Redis 作为系统缓存。

学科竞赛训练管理系统是我的毕业设计。本文内容因为删掉了与我个人和学校有关的隐私内容，测试和系统设计可能描述的不是很完整。

因为是用 3 天就完成了 90% 前后端开发工作，因此代码不是很简洁，出现了大量重复、冗余代码，尽情谅解。

虽然开发时间很充裕，但我并不想在毕业设计上花太多的时间（打游戏和学习不香吗），目标就是毕业即可。

懒得写针对性的代码，直接写了通用代码一把梭。

系统地址

前端地址

后端地址

系统介绍

针对目前高校举办学科竞赛所遇到的问题，本系统主要设计六个模块，分别是通知模块、战斗力模块、比赛模块、报名模块、角色模块和团队模块。

安装与使用教程

安装

服务器环境

服务器需要安装如表所示的软件。

名称	版本
Nginx	1.16
OpenJDK	11
数据库	Redis 5 PostgreSQL 12
Node.js	12

客户端环境

安装 IE 11 或所有现代浏览器。

Nginx 配置

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

    server {
        listen 80;

        gzip on;
        gzip_min_length 1k;
        gzip_comp_level 9;
        gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
        gzip_vary on;
        gzip_disable "MSIE [1-6]\.";

        root D:/AntDesignProjects/galop-web/dist;

        location / {
            try_files $uri $uri/ /index.html;
            rewrite ^/(.*)$ https://localhost/$1 permanent;
        }        
        location /api/ {
            proxy_pass https://localhost:8080/;
            proxy_set_header   X-Forwarded-Proto $scheme;
            proxy_set_header   X-Real-IP         $remote_addr;
        }
    }

    server {
        listen 443 ssl http2 default_server;

        ssl_certificate D:/IdeaProjects/galop-server/core-module/src/main/resources/galop.crt;
        ssl_certificate_key D:/IdeaProjects/galop-server/core-module/src/main/resources/galop.key;
        ssl_session_timeout  5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers AESGCM:ALL:!DH:!EXPORT:!RC4:+HIGH:!MEDIUM:!LOW:!aNULL:!eNULL;
        ssl_prefer_server_ciphers   on;
        
        root D:/AntDesignProjects/galop-web/dist;

        location / {
            try_files $uri $uri/ /index.html;
        }
        location /api/ {
            proxy_pass https://localhost:8080/;
            proxy_set_header   X-Forwarded-Proto $scheme;
            proxy_set_header   Host              $http_host;
            proxy_set_header   X-Real-IP         $remote_addr;
        }
    }
}

其中前端文件位置可以在 root 处定义，域名可以在 location 处定义，证书位置可以在 ssl\_certificate 和 ssl\_certificate\_key 处定义，可自行修改。

数据库配置

Redis 配置

spring:
  data:
    redis:
      repositories:
        enabled: true

  redis:
    # 数据库索引
    database: 0
    host: 127.0.0.1
    port: 6379
    password:
    # 连接超时时间
    timeout: 5000

可自行修改数据库服务器 IP 地址、端口号和密码。

PostgreSQL 配置

首先需要使用 galop\_20200502.sql 文件创建数据库，创建后进行如下数据库配置。

spring:
  datasource:
    druid:
      url: jdbc:postgresql://localhost:5432/galop
      username: postgres
      password: 123456

可自行修改数据库服务器 IP 地址、端口号、账号和密码。

其他配置

可自行修改 application.yml 中如表所示配置。

名称	默认值	备注
Excel 模板存储位置	`D:\IdeaProjects\galop-server\file\`	可选
邮箱配置		默认为空，必填
头像存储位置	`D:\IdeaProjects\galop-server\avatar\`	可选

建议配置

建议将前端代码放置在 D:\AntDesignProjects 文件夹下，将后端代码放置在 D:\IdeaProjects 文件夹下。这样可以直接使用自带的默认配置，仅需配置环境与邮箱。

配置完成后，前端需要执行 npm install 安装依赖，然后执行 umi build 编译。后端需要执行 mvn clean install 打包并发布到本地仓库。

运行

启动

运行 Nginx 服务器，Redis 和 PostgreSQL，然后运行编译后的 jar 包即可启动。

Windows 10 上具体操作如表所示。

命令	备注
启动 PowerShell
执行 `cd D:\Nginx\nginx-1.16.1\`	切换到 Nginx 安装目录
`start ./nginx.exe`	启动 Nginx 服务器
启动 WSL 2
执行 `redis-server`	启动 Redis
启动 PostgreSQL 服务	自行开启数据库服务
执行 `cd D:\IdeaProjects\galop-server\core-module\target\`	切换到后端编译出包位置
执行 `java -jar .\core-module-1.0.0.jar`	运行系统 jar 包

账号

系统初始内置一个管理员账号，账号为 000000，密码为 123456。

管理员可为其他人批量注册管理员或普通账号，注册后的默认密码为 123456。

运行

成功启动后可以通过浏览器访问 https://localhost/login 进行登录，登录后即可使用学科竞赛训练管理系统。

主要技术

开发环境

采用前后端分离的方式进行开发，具体环境如表所示。

名称	版本
操作系统	Windows 10
版本控制工具	Git 2.26
前端开发环境
开发工具	Visual Studio Code 1.44
Node.js	12.16
React	16.13
JavaScript	ECMAScript 6
Web 服务器	Nginx 1.16
后端开发环境
开发工具	IntelliJ IDEA 2020
OpenJDK	11
Spring Boot	2.2
数据库	Redis 5 PostgreSQL 12
Web 服务器	Tomcat 9

若干依赖不再详细列出。

运行环境

前端部署在 Nginx 服务器上，通过 Nginx 将 80 端口的请求转向 443 端口，然后将 443 端口的请求反向代理到后端的服务器上。

后端部署在装有 OpenJDK、Redis 和 PostgreSQL 的服务器上。

系统支持 IE 11 和所有现代浏览器访问。

系统设计

功能介绍

学科竞赛训练管理系统主要由通知模块、战斗力模块、比赛模块、报名模块、角色模块、团队模块以及工具模块组成。

通知模块

通知模块主要完成创建、查询、修改和删除公告的功能，通过自动化的方式来解决比赛组织和宣传成本高的问题。其中创建、修改和删除功能仅对老师开放，查询功能则对老师和学生开放。

比赛创建和比赛结果上传后，系统也会自动创建新的公告，如图所示。

老师和学生登录主页的最近十条公告功能也由通知模块提供。

战斗力模块

战斗力模块主要负责提供创建和查询学生战斗力变化情况的功能，通过每场比赛的结果计算战斗力并统计比赛人数，以可视化的图表来展现学生训练成果和比赛参与度。其中创建战斗力记录由系统自动完成，查询功能仅对学生开放。

学生登录主页的战斗力可视化图表和老师登录主页的比赛人数可视化图表功能也由战斗力模块提供，如图所示。

比赛模块

比赛模块主要完成创建比赛、查询和处理比赛结果的功能，通过自动化的方式来解决比赛结果处理繁琐以及训练效率低的问题。其中创建和上传比赛结果仅对老师开放，查询比赛功能对老师和学生开放，查询比赛结果功能仅对学生开放。

比赛创建和比赛结果上传后，系统会自动调用通知模块创建公告，如图所示。

尚未结束报名的比赛功能也由比赛模块提供，如图所示。

报名模块

报名模块主要完成比赛报名、审核和导出报名表的功能，学生可以从我的报名来看曾参加过的比赛与报名状态。通过自动化的方式解决老师难以选拔合适的参赛学生问题。其中比赛报名仅对团队队长开放，报名审核和导出报名表仅对老师开放，我的报名仅对学生开放。

老师可以根据学生所在团队的战斗力决定是否允许这个队伍参赛，如图所示。

角色模块

角色模块主要完成用户登录、查询、批量注册与注销、导出战斗力排名表、修改信息和重置密码的功能，通过自动化的方式解决注册、注销繁琐的问题。其中用户查询、批量注册与注销、导出战斗力排名和重置密码的功能仅对老师开放，登录与修改信息则对老师和学生开放。

批量注销后，角色模块会调用战斗力模块、比赛模块和团队模块删除信息。

用户忘记密码后，若注册时填写了邮箱，即可通过邮箱接收重置密码的邮件自己进行重置，如图所示。

若没有填写邮箱则可以通过联系老师进行密码重置。

团队模块

团队模块主要完成创建、查询、修改、发送加入申请和申请审核功能，用来解决学生组队困难的问题，如所示。

团队模块仅对学生开放。发送申请后，仅由团队的队长可见，如图所示。

工具模块

工具模块主要完成字符串处理、异常统一抛出、获取当前登录用户、Excel 读取与生成、Redis 配置、分页处理等功能。

前端

以创建比赛为例。

通过封装后的单选框 Radio 组件接收比赛类型的输入；通过封装后的 Input 组件接收比赛标题的输入；通过封装后的范围选择器 Range Picker 组件接收比赛时间的输入；通过封装 Input 组件后的 Input Number 组件接收要求团队人数、冠军所得奖励、递减梯度三种数字类型的输入；通过封装 Button 组件进行数据提交。

同时需要为以上组件统一编写数据验证规则，如非空判定和数据长度判定，以及对应的提示，防止提交空数据到后端。因此需要再封装一个 Form 组件统一管理提交、数据验证与数据说明。完成以上内容后效果如图所示。

本系统前端使用的架构是基于 Flux 的 Redux 架构。Redux 架构遵循三大原则，单一数据源、只允许触发 action 改变 state、reducer 必须为纯函数。action 作为 reducers 和 effects 的触发器，一般由 type 属性和 payload 属性组成。通过 type 属性寻找对应的 reducers 或 effects，将 payload 传递给它们。

因此当老师点击提交时，以上组件的 state 作为 payload，通过 payload 属性和 type 属性来触发 action 调用指定的 effects。当 action 触发 effects 之后，由 effects 将新增数据通过 HTTPS 请求发送给后端服务器，并接收后端服务器所返回的数据。根据返回数据判断是否成功，使用封装好的全局组件 Message 给出提示。完成以上内容后效果如图所示。

之所以调用 effects 而不是 reducer，是因为 Redux 架构要求 reducer 必须为纯函数。纯函数有两个特点，一是在执行过程中不会对外界产生影响；二是函数的参数与返回值是一一对应的，同一参数所得到的返回结果应该一致。在向服务端请求数据时，并不能保证参数与返回值一一对应；强制延时也会对外界产生影响，以上操作统称为副作用。因此，存在副作用的逻辑并不能写在 reducer 中。为了保证 reducer 是一个纯函数，同时又需要处理存在副作用的逻辑，那就需要打破“直接”这一特性。而 effect 则用来作为中间层。

effects 用于处理异步操作，例如将数据发送给后端服务器。但是根据 Redux 架构的约束，它不可以修改 state，必须再次触发 action 来调用 reducers 达成修改 state 的操作。从宏观角度看，effect 是一层中间件。从局部角度看，effect 就是一个 generator function。

effects 向服务器发起异步请求，但整体的执行结果却像同步一样。这是因为使用了 generator function 来处理异步逻辑。异步本质是事件的触发会导致程序跳转。使用 call 只是描述跳转的方式，并没有改变异步的本质，让程序看起来是同步的。

effect 的参数有两个，第一个对象可以获取 action 的 payload 字段，第二个对象则是 effect 的原语集，例如 call 和 put 就是原语集之一。其中 yield 和 call 配合可以处理异步逻辑，调用之后程序会进入阻塞状态，以此来等待服务器返回结果。得到结果后解除阻塞状态，继续执行。yield 和 put 配合可以再次触发一个 action，用来在 effect 中使用。

某一事件导致程序进行跳转，就是异步的本质。而 callback 可以看作一种描述异步的方法。generator function 通过修改这种描述的方法来让程序变成同步的样子。

在执行时 generator function 有两方。一方是本身，一方是句柄持有者，也就是框架。当框架调用这个句柄的 next 方法时，generator function 会在下一个 yield 前暂停，并把程序执行权和 yield 后面表达式的值交给框架。框架得到执行权和值后进行处理，结束后再次调用 next 方法，把值交还给 generator function，同时恢复运行。generator function 定义了程序执行流程，并在每一个 yield 告诉框架想要完成的任务。而异步任务真正的执行逻辑则交给了框架执行。

在向服务器发起请求时，对 fetch 进行了封装，便于做好统一异常处理。值得注意的是，在发送 HTTPS 请求时，请求的路径与后端服务器所在的路径并不相同。当请求协议不同、端口不同或路径不同时，我们就认为资源请求“跨域”了。而 HTTPS 的默认规则并不允许进行“跨域”请求。

本项目使用 Nginx 反向代理解决跨域的问题。Nginx 服务器监听来自前端的请求，然后将监听到的请求转发到后端服务器上。这样 Nginx 服务器与后端服务器就是服务器之间在进行通信，不存在跨域问题。

接下来继续看创建比赛的例子，effect 处理完毕后，再次触发 action，将服务器结果和 state 传递给 reducers，reducers 根据结果改变 state，然后通过新的 state 渲染页面。这样创建比赛的请求就完成了。

以多次触发 effect 为例，如图所示。

当 action 被触发后，首先需要解决一些副作用，如请求数据。这些操作需要通过 effect 来完成。然后 effect 会再次触发一个新的 action。这个新的 action 根据开发者的需要来指定 type，既可以被另一个 effect 捕获，然后继续处理副作用，也可以选择由 reducer 捕获，然后结束。无论如何，最终都会来到 reducer。

对于视图层，并没有办法察觉到 effect 和 reducer 的差别。视图层仅描述我想要通过 action 执行的操作，并不关心 action 之后是由 effect 到 reducer 处理，还是直接由 reducer 处理。这样我们就能够将数据逻辑与试图逻辑分离了。

reducer 的返回值会作为新的 state，重新渲染组件。而重新渲染组件是通过 connect 方法将新的 state 注入组件，进行渲染的。注入的本质是控制反转。有了 connect，组件不需要再管理数据，仅通过 connect 向框架描述所需的数据即可。React 也是如此，开发者并不需要直接操作 DOM，在组件中写一个返回视图的部分，这个部分就是向 React 描述我想要渲染的内容。React 负责将所描述的内容转换为 DOM，并决定渲染的时机。

后端

以查询比赛为例。

Nginx 转发的 HTTPS 请求访问后端服务器，Spring Security 拦截请求，进行 Token 验证。如图所示。

Spring Security 框架是用来防御常见攻击的框架。它可以提供身份验证和授权机制，并为 Authentication 和 Authorization 提供了解决方案。另外 Spring Security 框架不需要额外配置如身份验证、JAAS 策略等任何文件，使用十分便捷。

可以通过 SecurityContextHolder 的 getContext 方法获取 SecurityContext。我们通常通过 SecurityContext 获取 Authentication 对象，再从 Authentication 对象中取得 UserDetails，以得到详细的用户信息。

在登录时，Spring Security 通过 UserDetailsService 接口的实现类来获取登录用户的账号密码，然后由 AuthenticationManager 和 AuthenticationProvider 负责进行密码比对。之所以使用这样一个抽象的接口，是因为这样做 Spring Security 可以与持久层完全解耦，因此我保存 UserDetails 的 DAO 层可以是任何东西，数据库、缓存、Properties 文件或内存中都可以。

学科竞赛训练管理系统采用 JWT 方式来处理用户密码认证。JWT 作为无状态的授权校验技术，可以让后端不必保存用户状态。只需要在登录认证通过后，由后端生成一个 Token，把 Token 存入 Redis 并将 Token 返回给前端即可。前端之后的请求都要在请求头中携带 Token，后端接收 Token 后会对 Token 的格式、签名、以及权限进行验证，并与 Redis 中的 Token 进行比对。解析出权限后，根据 PreAuthorize 注解的配置进行权限验证，验证通过后则可以访问 RESTful API。当 Redis 的 Token 过期后，登录失效。具体原理如图所示。

可见 Spring Security 是由各种各样的 Filter 组成的。WebAsyncManagerIntegrationFilter 负责把 SecurityContext 保存在异步线程中，使异步线程也可以获取到用户信息；SecurityContextPersistenceFilter 负责读取或创建 SecurityContext，并存入 SecurityContextHolder 中；HeaderWriterFilter 负责给 HTTPS 请求添加一些请求头，如 X-Content-type-Options 等；LogoutFilter 负责处理退出登录；CorsFilter 负责跨域问题；TokenFilter 是自定义 Filter，负责验证 Token；RequestCacheAwareFilter 负责缓存 request 请求；SecurityContextHolderAwareRequestFilter 负责对 request 进行包装；AnonymousAuthenticationFilter 负责处理匿名登录；SessionManagementFilter 负责限制用户发起多次会话；ExceptionTranslationFilter 负责异常拦截，只处理未登录状态下访问受保护资源和登录后访问权限不足资源的异常；FilterSecurityInterceptor 负责授权验证，FilterSecurityInterceptor 通过 SecurityContextHolder 来得到 Authentication 对象，然后从 Authentication 对象中得到用户权限，将权限与用户想要访问的资源权限进行比对。

通过 SpringSecurity 验证后，即可访问 RESTful API。如图所示。

RESTful API 是一种遵守对方法、风格以及对体系结构的一些列约束的 API。一些后端服务可能是有着一个类似 /getxxx/1，使用 GET 或 POST 请求的服务，这样的可以称之为 RPC。因为无法知道应该如何与此服务进行交互，如果想要使用这样的项目那必须编写一个帮助文档来说明每一个服务的作用。很多人也将此称为 RESTful，但是它并不是。Roy Fielding 解释了 RESTful：只有由超文本驱动的 API，才能被称作是 RESTful API。由此可见，首先，要做到每个 URI 标识一种网络资源。资源是网络上的一个信息，如文本、图片或服务。其次，客户端与服务器之间以某种表现层传递这种资源。表现层是资源的表现形式，如图片可以使用 svg 格式，文本可以使用 json 格式表现出来。网址最后的 .html 实际是一种表现层，如果加上 .html 并不能说明这是资源的位置，只能说明这是资源的一种表现形式。最后，客户端通过 GET、POST 等原语操作对 URI 所代表的资源进行交互，以此将表现层的状态进行改变。HTTPS 协议是无状态协议，状态都会在服务端保存。因此想要改变表现层的状态，则只能使用 HTTPS 协议。只有做到以上三点，才可以被称为 RESTful API。

RESTful API 会对前端发来的数据进行验证，对于不需要返回数据的 API 来说，通过验证则将成功的信息返回，随后异步调用 Service 进行业务逻辑处理。若前端需要返回数据，如比赛查询需要返回查询结果，则同步调用 Service 处理，等待数据返回后将数据按前端需要的格式封装，将其返回。如图所示。

当数据通过验证后，则会传递给 Service 进行业务逻辑处理。在浏览比赛接口中，数据是查询条件和分页数据，Service 负责处理动态查询。

通过 Spring Data JPA 中的 JpaSpecificationExecutor 接口来实现动态查询。JpaSpecificationExecutor 接口提供了五种动态查询方法，分别是查询单条数据、查询多条数据、查询多条数据并排序、查询多条数据并分页与排序、查询数量。在浏览比赛接口中用到了分页并排序。

此方法定义如下：

Page findAll(@Nullable Specification var1, Pageable var2);

排序和分页只需要创建 Pageable 实例即可，如下所示：

PageRequest.of(当前页数, 每页展示数量, Sort.by(排序方式, 排序字段));

动态查询则创建 Specification 实例即可，如下所示：

Specification<T> specification = (Specification<T>) (root, criteriaQuery, criteriaBuilder) -> {
    ArrayList<Predicate> andQuery = new ArrayList<>();
    if (某查询条件 != null) {
        Path<字段类型> id = root.get(字段名);
        Predicate idEqual = criteriaBuilder.equal(id, 查询条件);
        andQuery.add(idEqual);
    }
……
    Predicate[] andPredicates = andQuery.toArray(new Predicate[0]);
    return criteriaBuilder.and(andPredicates);
};

最后只需要将 Specification 实例和 Pageable 实例作为参数即可实现动态查询。

以上是在缓存未命中的情况下才会执行，并且会将类地址、方法名、包名和参数作为键，将返回的结果作为值，存入缓存。若缓存存在，则无需执行以上代码，直接从缓存中取出数据即可。

当 Service 执行完毕后，会将返回的数据封装成前端所需的格式，存入请求体中返回。

测试

性能瓶颈

产生原因

因为本次测试以最坏情况为准，假设每人都会在查询团队之前创建新的团队，导致团队缓存失效，Redis 被穿透。因此涉及到团队查询的接口都会从数据库中进行查询，导致耗时较高。如表所示。

接口名	获取用户信息	获取战斗力变化数据	获取尚未结束的比赛	获取前十条公告	获取战斗力排行榜	获取团队信息	创建团队	获取比赛信息	比赛报名
平均值	65ms	34ms	33ms	31ms	29ms	1169ms	52ms	40ms	1094ms
90%	154ms	104ms	103ms	95ms	97ms	3146ms	122ms	126ms	1716ms

因获取团队信息和比赛报名接口都涉及到了查询团队信息，因此在缓存被穿透的情况下耗时异常的高。

优化方案

因本系统性能目前已达到预计要求，所以仅提出以下理论优化方案，不做具体实现。

因查询团队性能瓶颈是由 Redis 缓存失效导致，所以可以建立二级缓存。当缓存失效时，为数据表加锁，保证只有一个进程进行数据库的查询。其他进程发现加锁后返回二级缓存中的数据，查询完毕后再更新对应的缓存即可。尽管只有拿到锁的用户可以看到最新数据，一部分人没有及时看到最新的数据，但是这部分人只是少数，只需要刷新一下就可以看到最新数据了。

用以上方案缓解 Redis 失效问题后再次压测，系统指标一切正常，实际 TPS 大于预计的 275TPS，90% 的请求最大响应时间为 186ms，平均值为 75ms，可以满足学生报名需求。

搜索引擎使用教程

Tue, 24 Dec 2019 13:03:00 +0800

前言

尽管人们经常使用搜索引擎，但有时候对于一些问题可能无法高效搜索，会搜出来许多无用的干扰信息。

对于知识工作者而言，搜索这个技能可以说是渗透到学习闭环的各个环节。因此学习一下搜索引擎的使用技巧，提高效率，可以避免时间浪费。

搜索引擎推荐

Google

全球第一，即使搜索中文关键词也强于百度。

百度

中国第一，搜索娱乐新闻等十分好用。

计算机专业不推荐使用，大多数技术网站都对百度做了反爬虫，百度是无法搜索到的。

Bing

针对中文进行了优化，是无法访问 Google 时最好的替代品。

推荐国际版，无广告。

搜索技巧

Google

如上，这是 Google 提供的高级搜索方式。

百度

如上，这是百度提供的高级搜索方式。

Bing

Bing 并未提供可视化的高级搜索方式。

搜索技巧

一般来说通过使用各搜索引擎提供的可视化高级搜索工具可以解决大多数需求。

但有一些好用的搜索引擎并没有提供可视化高级搜索工具，并且可视化高级搜索工具用起来也略微繁琐。

那么以下内容则是介绍不通过可视化的方式来进行高级搜索的方法。

关键字选取

搜索最重要的就是关键词。现在搜索引擎对于语义搜索、情景搜索、智能推荐等已经做得很好了，以前自行提取关键词的方式并不适用于现在。

因此我们在进行搜索的时候，既可以直接输入问题，也可以自行提取 1 - 3 个关键词进行搜索。

另外也可以用不同的语言来搜索。

完全匹配

用引号将需要完全匹配的字词引起："可口可乐"，即可进行完全匹配，并不会搜到 可乐 这样的关键词。

任意匹配

在所需字词之间添加 OR：可口 OR 百事。

不包含匹配

在不需要的字词前添加一个减号：-可口。

数字范围

在数字之间加上两个句号并添加度量单位：10..35 斤、300..500 元、2010..2011 年。

不常用操作

以下操作较为繁琐，也很少用。

filetype 搜索对应类型的文件。

site 在某个网站内搜索。

allintitle 搜索网页标题中包含关键词的结果。

allintext 搜索网页文本中包含关键词的结果。

allinurl 搜索网页网址中包含关键词的结果。

allinanchor 搜索指向网页的链接中包含关键词的结果。

related 搜索相关网站。

index of 可以突破网站入口下载。

关于

Mon, 01 Jan 0001 00:00:00 +0000

介绍

欢迎访问我的博客，我是一名 2020 年毕业的后端研发工程师，目前在北京工作，就职于京东。

工作中主要负责支付营销工具的开发与稳定性保障。在这期间，支撑过若干次 618、1111 大促，以及春晚亿级流量营销，有较为丰富的亿级流量高并发系统设计与实战经验。相信大家在京东购物时一定都用过我负责的系统服务。

平时爱好读书与思考，研究一些让我好奇的东西。偶尔会玩玩尤克里里与 Nintendo Switch，享受一个人的平静生活。

技能清单

语言: Java、Lua、Groovy、C、SQL、Shell、HTML、CSS、JavaScript 等
版本管理: Git
数据库: MySQL、CDS(自研分布式数据库)、PostgreSQL、JimDB(自研 NoSQL 数据库及缓存)、Redis、HBase、Elasticsearch
常用 Linux 发行版: CentOS、Debian 等
其他常用中间件、开发组件、工具: Spring Boot、MyBatis、Spring Data JPA、JSF(自研微服务平台，类似 Dubbo 等)、EasyJob(自研分布式调度平台，类似 ElasticJob)、Kafka、JMQ(自研分布式事件流平台，类似 Kafka)、Flink、NFS、HDFS、Docker、Caffeine Cache、Tomcat、Nginx、Netty 等

博客

我一直认为，定期记录自己的生活与工作，是一件很有意义的事。所以，不论是生活中的大太阳还是小乌云，我都会在博客中记录下来。若干年后回过头来看看自己的点点滴滴，一定会很有成就感。

除了分享自己的生活，我还会记录自己在职业发展、学习成长路上的经验与心得。学习路上应该做好复盘，时时刻刻整理自己的收获，才可以走得更远。

如果各位在浏览过程中，发现有些方面理解的有偏差，或者想要交流，可以直接留言或者发邮件。非常期待各位的指教。

网站信息

名称：张天赐的小世界
描述：一个记录自己生活历程的纸飞机
链接：https://www.zhangtianci.cn

排版

全博客使用中文文案排版指北进行排版。

许可协议

本博客的作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

使用者可以对本创作进行转载、节选、混编、二次创作，但不得运用于商业目的，且使用时须进行署名，采用本创作的内容必须同样采用本协议进行授权。