在涉及到支付的业务时，通常需要实现一个功能:如果用户在生成订单的一定时间内未完成支付，系统将自动取消订单。本文将基于Spring Boot框架实现订单30分钟内未支付自动取消的几种方案，并提供实例代码。

方案一：定时任务

利用@Scheduled注解，我们可以轻松实现定时任务，周期性扫描订单记录，检查未支付的订单，如果有满足三十分钟则进行关闭。

@Component

public class OrderSchedule {

    @Autowired

    private OrderService orderService;



    @Scheduled(cron = "0 0/1 * * * ?")

    public void cancelUnpaidOrders() {

        LocalDateTime now = LocalDateTime.now();

        List<Integer> idList = new ArrayList<Integer>();

        List<OrderEntity> orderList = orderService.getOrderList();

        orderList.forEach(order -> {

            if (order.getWhenCreated().plusMinutes(30).isBefore(now)) {

                idList.add(order.getId());

          }

        });

        orderService.cancelOrderList(idList);

        }

}

方案二：延迟队列

使用消息队列的延迟队列，当订单生成时将订单ID推送到延迟队列，设置30分钟后过期，过期后消费该消息，判断订单状态，如果未支付则取消订单。

@Service

public class OrderService {



    @Autowired

    private RabbitTemplate rabbitTemplate;



    public void createOrder(Order order) {

        // 保存数据库

        saveOrder(order);



        // 将订单ID推送至延迟队列

        rabbitTemplate.convertAndSend("orderDelayExchange", "orderDelayKey", order.getId(), message -> {

            message.getMessageProperties().setDelay(30 * 60 * 1000); // 设置延迟时间

            return message;

        });

    }

}



@Component

public class OrderDelayConsumer {



    @Autowired

    private OrderService orderService;



    @RabbitHandler

    @RabbitListener(queues = "orderDelayQueue")

    public void cancelOrder(String orderId) {

        // 取消订单

        orderService.cancelOrder(orderId);

    }

}

方案三：redis过期事件

使用redis的key过期事件，当订单创建时在Redis中存储一个key，设置30分钟过期，key过期时通过redis的过期事件通知功能触发订单取消。

@Service

public class OrderService {



    @Autowired

    private StringRedisTemplate redisTemplate;



    public void createOrder(Order order) {

        // 保存订单至数据库

        saveOrder(order);



        // 在redis中存储一个key，设置30分钟过期

        redisTemplate.opsForValue().set("order:" + order.getId(), order.getId(), 30, TimeUnit.MINUTES);

    }



    // 当key过期时，redis会自动调用该方法（需要配置redis的过期事件通知）

    public void onOrderKeyExpired(String orderId) {

        cancelOrder(orderId);

    }

}

注：redis的key过期通知是一种典型的发布-订阅模式。在redis中，我们可以订阅到某些特定的事件。key过期事件就是其中之一。但想要使用这个功能，需要redis服务器开启相关配置。具体如何配置会在后期的文章里分享给大家。

最后总结：

三种方案都可以实现订单在30分钟内未支付则自动取消的需求。根据实际业务需求、系统负载和其他因素，可以选择最适合自己系统的实现方案。每种方案都有其优缺点，需要根据具体情况权衡。

你好呀，我是歪歪。

踩坑了啊，最近踩了一个 lombok 的坑，有点意思，给你分享一波。

我之前写过一个公共的服务接口，这个接口已经有好几个系统对接并稳定运行了很长一段时间了，长到这个接口都已经交接给别的同事一年多了。

因为是基础服务嘛，相对稳定，所以交出去之后他也一直没有动过这部分代码。

但是有一天有新服务要对接这个接口，同事反馈说遇到一个诡异的问题，这个新服务调用的时候，接口里面报了一个空指针异常。

根据日志来看，那一行代码大概是这样的：

//为了脱敏我用field1、2、3来代替了

if(reqDto.getField1() 

    && reqDto.getField2()!=null

    && reqDto.getField3()!=null){

        //满足条件则执行对应业务逻辑

    }

reqDto 是接口入参对象，有好多字段。具体到 field1、2、3 大概是这样的：

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

所以看到这一行抛出了空指针异常，我直接就给出了一个结论：首先排除 field1 为 null，因为有默认值。那只可能 reqDto 传进来的就是 null，导致在 get 字段的时候出现了空指针异常。

但是很不幸，这个结论一秒就被推翻了。

因为 reqDto 是请求入参，在方法入口处选了几个关键字段进行打印。

如果 reqDto 是 null 的话，那么日志打印的时候就会先抛出空指针异常了。

然后我又开始怀疑是部署的代码版本和我们看的版本不一致，可能并不是这一行报错。

和测试同学确认之后，也排除了这个方向。

盯着报错的那一行代码又看了几秒，排除所有不可能之后，我又下了一个结论：调用的时候，传递进来的 field1 主动设值为了 null。

也就是说调用方有这样的代码：

ReqDto reqDto = new ReqDto();

reqDto.setField1(null);

我知道，这样的代码看起来很傻，但是确实只剩下这一种可能了。

于是我去看了调用方构建参数的写法，准备吐槽一波为什么要写设置为 null 这样的坑爹代码。

然而，当时我就被打脸了，调用方的代码是这样的：

ReqDto reqDto = ReqDto.builder()

        .field2("why")

        .field3("max")

        .build();

用的是 builder 模式构建的对象，并不是直接 new 出来的对象。

我一眼看着这个代码也没有发现毛病，虽然没有对 Boolean 类型的 field1 进行设值，但是我有默认值啊。

问调用方为什么不设值，对方的回答也是一句话：我看你有默认值，我本来也是想传 true，但是一看你的默认值就是 true，所以就没有给值了。

对啊，这逻辑无懈可击啊，难道......

是 builder 在里面搞事情了？

于是我里面写了一个代码进行了验证：

好你个浓眉大眼的 @Builder，果然是你在搞事情。

问题现象基本上就算是定位到了，用 @Builder 注解的时候，丢失默认值了。

所以拿着 “@Builder 默认值” 这样的关键词一搜：

立马就能找到这样的一个注解：@Builder.Default

对应到我的案例应该是这样的：

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    @Builder.Default

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

这样，再次运行 Demo 就会发现有默认值了：

同时我们从两个写法生成的 class 文件中也可以看出一些端倪。

没有@Builder.Default 注解的时候，class 文件中 ReqDtoBuilder 类中关于 field1 字段是这样的：

但是有 @Builder.Default 注解的时候，是这样的：

明显是不同的处理方式。

反正，网上一搜索，加上 @Builder.Default 注解，问题就算是解决了。

但是紧接着我想到了另外一个问题：为什么？

为什么我明明给了默认值，@Builder 不使用，非得给再显示的标记一下呢？

于是我带着这个问题在网上冲了一大圈，不说没有找到权威的回答了，甚至没有找到来自“民间”的回答。

所以我也只能个人猜测一下，我觉得可能是 Lombok 觉得这样的赋默认值的写法是 Java 语言的规范：

private Boolean field1 = true;

规范我 Lombok 肯定遵守，但是我怎么知道你这个字段有没有默认值呢？

我肯定是有手段去检查的，但是我必须要每个字段都盲目的去瞅一眼，这个方案对我不友好啊。

这样，我给使用者定一个规范：你给我打个标，主动告诉我那些字段是有默认值的。对于打了标的字段，我才去解析对应的默认值，否则我就不管了。

如果你直接 new 对象，那是 Java 的规范，我管不了。

但是如果你使用 Builder 模式，你就得遵守我的规范。不然出了问题也别赖我，谁叫你不准守我的规范。

打个标，就是 @Builder.Default。

必须要强调的是，这个观点是歪师傅纯粹的个人想法，不保真。如果你有其他的看法也可以提出来一起交流，学习一波。

吃个瓜

虽然我没有找到关于 @Builder.Default 注解存在的意义的官方说明，但是我在 github 上找到了这个一个链接：

github.com/projectlomb…

里面的讨论的问题和我们这个注解有点关系，而且我认为这是一个非常明确的 bug，但是官方却当做 feature 给处理了。

简单的一起吃个瓜。

2017 年 3 月 29 日的时候，一个老哥抛出了一个问题。

首先我们看一下提出问题的老哥给的代码：

就上面这个代码，如果我们这样去创建对象：

MyClass myClass = new MyClass();

按照 Java 规范来说，我们附了默认值的，调用 myClass.getEntitlements() 方法返回的肯定是一个空集合嘛。

但是，这个老哥说当 new MyClass 对象的时候，这个字段变成了 null：

他就觉得很奇怪，于是抛出了这个问题。

然后另外有人立马补充了一下。说不仅是 list/set/map，任何其他 non-primitive 类型都会出现这个问题：

啥意思呢，拿我们前面的案例来说就是，你用 1.16.16 这个版本，不加 @Builder.Default 注解，运行结果是符合预期的：

但是加上 @Builder.Default 注解，运行结果会变成这样：

build 倒是正确了，但是 new 对象的时候，你把默认值直接给干没了。

看到这个运行结果的第一个感觉是很奇怪，第二个感觉是这肯定是 lombok 的 BUG。

问题抛出来之后，紧接着就有老哥来讨论了：

这个哥们直接喊话官方：造孽啊，这么大个 BUG 还有没有人管啦？

同时他还抛出了一个观点：老实说，为字段生成默认值的最直观方法就是从字段初始化中获取值，而不是需要额外的 Builder.Default 注解来标记。

这个观点，和我前面的想法倒是不谋而合。但是还是那句话：一切解释权归官方所有，你要用，就得遵守我制定的规范。

那么到底是改了啥导致产生了这么一个奇怪的 BUG 呢？

注意 omega09 这个老哥的发言的后半句：field it will be initialized twice.

initialized twice，初始化两次，哪来的两次？

我们把目光放到这里来：

@NoArgsConstructor，这是个啥东西？

这不就是让 lombok 给我们搞一个无参构造函数吗？

搞无参构造函数的时候，不是得针对有默认值的字段，进行一波默认值的初始化吗？

这个算一次了。

前面我们分析了 @Builder.Default 也要对有默认值的字段初始化一次。

所以是 twice，而且这两次干得都是同一个活。

开发者一看，这不行啊，得优化啊。

于是把 @NoArgsConstructor 的初始化延迟到了 @Builder.Default 里面去，让两次合并为一次了。

这样一看，用 Builder 模式的时候确实没问题了，但是用 new 的时候，默认值就没了。

这是一种经典的顾头不顾尾的解决问题的方式。

作者可能也没想到，大家在使用的时候会把 @Builder 和 @NoArgsConstructor 两个注解放在一起用。

作者可能还觉得委屈呢：这明明就是两种不同的对象构建方式啊，二选一就行了，你要放在一起？哎哟，你干嘛~

接着一个叫做 davidje13 的老哥接过了话茬，顺着 omega09 老哥的话往下说，他除了解释两个注解放在一起使用的场景外，还提到了一个词：least-surprise。

least-surprise，是一个软件设计方面的词汇，翻译过来就是最小惊吓原则。

简单来说就是我们的程序所表现出的行为，应该尽量满足在其领域内具有一致性、显而易见、可预测、遵循惯例。

比如我们认为的惯例是 new 对象的时候，如果有默认值会附上默认值。

结果你这个就搞没了，就不遵循惯例了。

当然，你还是可以拿出那句万金油的话：一切解释权归官方所有，你要用，就得遵守我制定的规范。我的规范就是不让你们混用。

这就是纯纯的耍无赖了，相当于是做了一个违背祖宗的决定。

然而这个问题似乎并没有官方人员参与讨论，直到这个时候，2018 年 3 月 27 日：

rspiller 就是官方人员，他说：我们正在调查此事。

此时，距离这个问题提出的时间已经过去了一年。

我是比较吃惊的，因为我认为这是一个比较严重的 BUG 了，程序员在使用的时候会遇到一些就类似于我认为这个字段一定是有默认值的，但是实际上却变成了 null 这种莫名其妙的问题。

在官方人员介入之后，这个问题再次活跃起来。

一位 xak2000 老哥也发表了自己的看法，并艾特了官方人员：

他的观点我是非常认同的，给你翻译一波。

他说，导致这个问题的原因是为了消除可能出现的重复初始化。但实际上，与修改 POJO 字段的默认初始化这种完全出乎意料的行为相比，重复初始化的问题要小得多。

当然，解决这个问题的最佳方法是以某种方式摆脱双重初始化，同时又不破坏字段初始化器。

但如果这不可能，或者太难，或者时间太长，那么，就让重复初始化发生吧！

然后把“重复初始化”写到 @Builder.Default javadocs 中，大不了再给这几个字加个粗。

如果有人确实写了一些字段初始化比较复杂的程序，这可能会导致一些问题，但比起该初始化却没有初始化带来的问题要少得多。

在当前的这个情况下，当突然抛出一个空指针异常的时候，我真的很蒙蔽啊。

当然了，也有人提出了不一样的看法：

这个哥们的核心思路刚刚相反，就是呼吁大家不要把 @Builder 和 @NoArgsConstructor 混着用。

从“点赞数”你也能看出来，大家都不喜欢这个方案。

而这个 BUG 是在 2018 年 7 月 26 日，1.18.2 版本中才最终解决的：

projectlombok.org/changelog

此时，距离这个问题提出，已经过去了一年又四个月。

值得注意的是，在官方的描述里面，用的是 FEATURE 而不是 BUGFIX。

个中差异，你可以自己去品一品。

但是现在 Lombok 都已经发展到 1.18.32 版本了，1.16.x 版本应该没有人会去使用了。

所以，大家大概率是不会踩到这个坑的。

我觉得这个事情，了解“坑”具体是啥不重要，而是稍微走进一下开源项目维护者的内心世界。

开源不易，有时候真的就挺崩溃的。

编译时注解

既然聊到 Lombok 了，顺便也简单聊聊它的工作原理。

Lombok 的核心工作原理就是编译时注解，这个你知道吧？

不知道其实也很正常，因为我们写业务代码的时候很少自定义编译时注解，顶天了搞个运行时注解就差不多了。

其实我了解的也不算深入，只是大概知道它的工作原理是什么样的，对于源码没有深入研究。

但是我可以给你分享一下两个需要注意的地方和可以去哪里了解这个玩意。

以 Lombok 的日志相关的注解为例。

首先第一个需要注意的地方是这里：

log 相关注解的源码位于这个部分，可以看到很奇怪啊，这些文件是以 SCL.lombok 结尾的，这是什么玩意？

这是 lombok 的小心思，其实这些都是 class 文件，但是为了避免污染用户项目，它做了特殊处理。

所以你打开这类文件的时候选择以 class 文件的形式打开就行了，就可以看到里面的具体内容。

比如你可以看看这个文件：

lombok.core.handlers.LoggingFramework

你会发现你们就像是枚举似的，写了很多日志的实现：

这个里面把每个注解需要生成的 log 都硬编码好了。正是因为这样，Lombok 才知道你用什么日志注解，应该给你生成什么样的 log。

比如 log4j 是这样的：

private static final org.apache.logging.log4j.Logger log = org.apache.logging.log4j.LogManager.getLogger(TargetType.class);

而 SLF4J 是这样的：

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(TargetType.class);

第二个需要注意的地方是找到入口:

这些 class 文件加载的入口在于这个地方，是基于 Java 的 SPI 机制：

AnnotationProcessorHider 这个类里面有两行静态内部类，我们看其中一个， AnnotationProcessor ，它是继承自 AbstractProcessor 抽象类：

javax.annotation.processing.AbstractProcessor

这个抽象类，就是入口中的入口，核心中的核心。

在这个入口里面，初始化了一个类加载器，叫做 ShadowClassLoader：

它干的事儿就是加载那些被标记为 SCL.lombok 的 class 文件。

然后我是怎么知道 Lombok 是基于编译时注解的呢？

其实这玩意在我看过的两本书里面都有写，有点模糊的印象，写文章的时候我又翻出来读了一遍。

首先是《深入理解 Java 虚拟机(第三版)》的第四部分程序编译与代码优化的第 10 章：前端编译与优化一节。

里面专门有一小节，说插入式注解的：

Lombok 的主要工作地盘，就在 javac 编译的过程中。

在书中的 361 页，提到了编译过程的几个阶段。

从 Java 代码的总体结构来看，编译过程大致可以分为一个准备过程和三个处理过程：

• 1.准备过程：初始化插入式注解处理器。


• 2.解析与填充符号表过程，包括：
  
  
  
  
  • 词法、语法分析。将源代码的字符流转变为标记集合，构造出抽象语法树。
  
  
  • 填充符号表。产生符号地址和符号信息。
  
  
  
  


• 3.插入式注解处理器的注解处理过程：插入式注解处理器的执行阶段，本章的实战部分会设计一个插入式注解处理器来影响Javac的编译行为。


• 4.分析与字节码生成过程，包括：
  
  
  
  
  • 标注检查。对语法的静态信息进行检查。
  
  
  • 数据流及控制流分析。对程序动态运行过程进行检查。
  
  
  • 解语法糖。将简化代码编写的语法糖还原为原有的形式。（java中的语法糖包括泛型、变长参数、自动装拆箱、遍历循环foreach等，JVM运行时并不支持这些语法，所以在编译阶段需要还原。）
  
  
  • 字节码生成。将前面各个步骤所生成的信息转换成字节码。
  
  
  
  

如果说 javac 编译的过程就是 Lombok 的工作地盘，那么其中的“插入式注解处理器的注解处理过程”就是它的工位了。

书中也提到了 Lombok 的工作原理：

第二本书是《深入理解 JVM 字节码》，在它的第 8 章，也详细的描述了插件化注解的处理原理，其中也提到了 Lombok：

最后画了一个示意图，是这样的：

如果你看懂了书中的前面的十几页的描述，那么看这个图就会比较清晰了。

总之，Lombok 的核心原理就是在编译期对于 class 文件的魔改，帮你生成了很多代码。

如果你有兴趣深入了解它的原理的话，可以去看看我前面提到的这两本书，里面都有手把手的实践开发。

我就不写了，一个原因是因为确实门槛较高，写出来生涩难懂，对我们日常业务开发帮助也不大。

另外一个原因那不是因为我懒嘛。

荒腔走板

周末去了一趟都江堰。

问道青城山，拜水都江堰。读大学的时候就知道这句话了，所以从大学算起，都江堰景区去过的次数，没有十次也有七八次了。

之前每次去就是觉得：哇，好大的山；哇，好急的水；哇，这个一点也不像鱼嘴的地方为什么叫鱼嘴；哇，这个鱼嘴看介绍很牛逼，但是我感觉我上我也行的样子。

这次去的时候，我和 Max 同学算是自己做了一次攻略，看了相关的介绍视频，比较系统的了解了一下鱼嘴、飞沙堰、宝瓶口的作用。

如果你也有兴趣的话，推荐看看 B 站“星球研究所”有一期将都江堰的视频，简短且直观，很不错。

看视频的时候才知道原来这里面有这么多门道，并惊叹于古人的智慧和劳动能力。顺应自然规律，因时制宜，建造了都江堰水利工程，并一直沿用了约 2300 年。

当我们真的走进景区，看到鱼嘴、飞沙堰、宝瓶口就在眼前的时候，才真正明白了视频里面说的“四六分水、二八排沙”是怎么回事，“深淘摊，低作堰”又是怎么回事。

水旱从人，不知饥谨，时无荒年，天下谓之天府也。

成都不能没有都江堰。

李冰父子，配享太庙。

为什么很多人不推荐你用JWT?

如果你经常看一些网上的带你做项目的教程，你就会发现 有很多的项目都用到了JWT。那么他到底安全吗？为什么那么多人不推荐你去使用。这个文章将会从全方面的带你了解JWT 以及他的优缺点。

什么是JWT?

这个是他的官网JSON Web Tokens - jwt.io

这个就是JWT

JWT 全称JSON Web Token

如果你还不熟悉JWT，不要惊慌！它们并不那么复杂！

你可以把JWT想象成一些JSON数据，你可以验证这些数据是来自你认识的人。

当然如何实现我们在这里不讲，有兴趣的可以去自己了解。

下面我们来说一下他的流程：

为什么说JWT很烂？

首先我们用JWT应该就是去做这些事情：

• 用户注册网站


• 用户登录网站


• 用户点击并执行操作


• 本网站使用用户信息进行创建、更新和删除 信息

这些事情对于数据库的操作经常是这些方面的

• 记录用户正在执行的操作


• 将用户的一些数据添加到数据库中


• 检查用户的权限，看看他们是否可以执行某些操作

之后我们来逐步说出他的一些缺点

大小

这个方面毋庸置疑。

比如我们需要存储一个用户ID 为xiaou

如果存储到cookie里面，我们的总大小只有5个字节。

如果我们将 ID 存储在 一个 JWT 里。他的大小就会增加大概51倍

这无疑就增大了我们的宽带负担。

冗余签名

JWT的主要卖点之一就是其加密签名。因为JWT被加密签名，接收方可以验证JWT是否有效且可信。

但是，在过去20年里几乎每一个网络框架都可以在使用普通的会话cookie时获得加密签名的好处。

事实上，大多数网络框架会自动为你加密签名（甚至加密！）你的cookie。这意味着你可以获得与使用JWT签名相同的好处，而无需使用JWT本身。

实际上，在大多数网络身份验证情况下，JWT数据都是存储在会话cookie中的，这意味着现在有两个级别的签名。一个在cookie本身上，一个在JWT上。

令牌撤销问题

由于令牌在到期之前一直有效，服务器没有简单的方法来撤销它。

以下是一些可能导致这种情况危险的用例。

注销并不能真正使你注销！

想象一下你在推特上发送推文后注销了登录。你可能会认为自己已经从服务器注销了，但事实并非如此。因为JWT是自包含的，将在到期之前一直有效。这可能是5分钟、30分钟或任何作为令牌一部分设置的持续时间。因此，如果有人在此期间获取了该令牌，他们可以继续访问直到它过期。

可能存在陈旧数据

想象一下用户是管理员，被降级为权限较低的普通用户。同样，这不会立即生效，用户将继续保持管理员身份，直到令牌过期。

JWT通常不加密

因此任何能够执行中间人攻击并嗅探JWT的人都拥有你的身份验证凭据。这变得更容易，因为中间人攻击只需要在服务器和客户端之间的连接上完成

安全问题

对于JWT是否安全。我们可以参考这个文章

JWT （JSON Web Token） （in）security - research.securitum.com

同时我们也可以看到是有专门的如何攻击JWT的教程的

高级漏洞篇之JWT攻击专题 - FreeBuf网络安全行业门户

总结

总的来说，JWT适合作为单次授权令牌，用于在两个实体之间传输声明信息。

但是，JWT不适合作为长期持久数据的存储机制，特别是用于管理用户会话。使用JWT作为会话机制可能会引入一系列严重的安全和实现上的问题，相反，对于长期持久数据的存储，更适合使用传统的会话机制，如会话cookie，以及建立在其上的成熟的实现。

但是写了这么多，我还是想说，如果你作为自己开发学习使用，不考虑安全，不考虑性能的情况下，用JWT是完全没有问题的，但是一旦用到生产环境中，我们就需要避免这些可能存在的问题。

首发公众号:【赵侠客】

引言

我相信作为一名java开发者你一定听过或者看过类似《你还在用for循环遍历List吗？》、《JDK8都10岁了，你还在用for循环遍历List吗？》这类鄙视在Java中使用for循环遍历List的水文。这类文章说的其实就是使用Java8中的Stream.foreach()来遍历元素，在技术圈感觉使用新的技术就高大上，开发者们也都默许接受新技术的很多缺点，而使用老的技术或者传统的方法就会被人鄙视，被人觉得Low，那么使用forEach()真的很高大上吗？它真的比传统的for循环好用吗？本文就列出10大推荐使用for而不是forEach()的理由。

理由一、for性能更好

在我的固有认知中我是觉得for的循环性能比Stream.forEach()要好的，因为在技术界有一条真理：

越简单越原始的代码往往性能也越好

而且搜索一些文章或者大模型都是这么觉得的，可时我并没有找到专业的基准测试证明此结论。那么实际测试情况是不是这样的呢？虽然这个循环的性能差距对我们的系统性能基本上没有影响，不过为了证明for的循环性能真的比Stream.forEach()好我使用基准测试用专业的实际数据来说话。我的测试代码非常的简单，就对一个List<Integer> ids分别使用for和Stream.forEach()遍历出所有的元素，以下是测试代码：

@State(Scope.Thread)

public class ForBenchmark {

    private List<Integer> ids ;

    @Setup

    public void setup() {

        ids = new ArrayList<>();

        //分别对10、100、1000、1万、10万个元素测试

        IntStream.range(0, 10).forEach(i -> ids.add(i));

    }

    @TearDown

    public void tearDown() {

        ids = new ArrayList<>();

    }

    @Benchmark

    public void testFor() {

        for (int i = 0; i <ids.size() ; i++) {

            Integer id = ids.get(i);

        }

    }



    @Benchmark

    public void testStreamforEach() {

        ids.stream().forEach(x->{

            Integer id=x;

        });

    }



    @Test

    public void testMyBenchmark() throws Exception {

        Options options = new OptionsBuilder()

                .include(ForBenchmark.class.getSimpleName())

                .forks(1)

                .threads(1)

                .warmupIterations(1)

                .measurementIterations(1)

                .mode(Mode.Throughput)

                .build();

        new Runner(options).run();

    }

}

我使用ArrayList分对10、100、1000、1万，10万个元素进行测试，以下是使用JMH基准测试的结果，结果中的数字为吞吐量，单位为ops/s，即每秒钟执行方法的次数：

从使用Benchmark基准测试结果来看使用for遍历List比Stream.forEach性能在元素越小的情况下优势越明显，在10万元素遍历时性能反而没有Stream.forEach好了，不过在实际项目开发中我们很少有超过10万元素的遍历。

所以可以得出结论：

在小List(万元素以内)遍历中for性能要优于Stream.forEach

理由二、for占用内存更小

Stream.forEach()会占用更多的内存，因为它涉及到创建流、临时对象或者对中间操作进行缓存。for 循环则更直接，操作底层集合，通常不会有额外的临时对象。可以看如下求和代码，运行时增加JVM参数-XX:+PrintGCDetails -Xms4G -Xmx4G输出GC日志：

• 使用for遍历

List<Integer> ids = IntStream.range(1,10000000).boxed().collect(Collectors.toList());

int sum = 0;

for (int i = 0; i < ids.size(); i++) {

    sum +=ids.get(i);

}

System.gc();

//GC日志

[GC (System.gc()) [PSYoungGen: 392540K->174586K(1223168K)] 392540K->212100K(4019712K), 0.2083486 secs] [Times: user=0.58 sys=0.09, real=0.21 secs]                               

从GC日志中可以看出，使用for遍历List在GC回收前年轻代使用了392540K，总内存使用了392540K，回收耗时0.20s

• 使用stream

List<Integer> ids = IntStream.range(1,10000000).boxed().collect(Collectors.toList());

int sum = ids.stream().reduce(0,Integer::sum);

System.gc();

//GC日志

[GC (System.gc()) [PSYoungGen: 539341K->174586K(1223168K)] 539341K->212118K(4019712K), 0.3747694 secs] [Times: user=0.55 sys=0.83, real=0.38 secs]                              

从GC日志中可以看出，回收前年轻代使用了539341K，总内存使用了539341K，回收耗时0.37s ，从内存占用情况来看使用for会比Stream.forEach()占用内存少37%，而且Stream.foreach() GC耗时比for多了85%。

理由三、for更易控制流程

我们使用for遍历List可以很方便的使用break、continue、return来控制循环，而使用Stream.forEach在循环中是不能使用break、continue，特别指出的使用return是无法中断Stream.forEach循环的，如下代码：

List<Integer> ids = IntStream.range(1,4).boxed().collect(Collectors.toList());

ids.stream().forEach(i->{

    System.out.println(""+i);

    if(i>1){

        return;

    }

});

System.out.println("==");

for (int i = 0; i < ids.size(); i++) {

    System.out.println(""+ids.get(i));

    if(ids.get(i)>1){

        return;

    }

}

输出：

forEach-1

forEach-2

forEach-3

==

for-1

for-2

从输出结果可以看出在Stream.forEach中使用return后循环还会继续执行的，而在for循环中使用return将中断循环。

理由四、for访问变量更灵活

这点我想是很多人在使用Stream.forEach中比较头疼的一点，因为在Stream.forEach中引用的变量必须是final类型，也就是说不能修改forEach循环体之外的变量，但是我们很多业务场景就是修改循环体外的变量，如以下代码:

Integer sum=0;

for (int i = 0; i < ids.size(); i++) {

    sum++;

}



ids.stream().forEach(i -> {

    //报错

    sum++;

});

像上面的这样的代码在实际中是很常见的，sum++在forEach中是不被允许的，有时为了使用类似的方法我们只能把变量变成一个引用类型：

AtomicReference<Integer> sum= new AtomicReference<>(0);

ids.stream().forEach(i -> {

    sum.getAndSet(sum.get() + 1);

});

所以在访问变量方面for会更加灵活。

理由五、for处理异常更方便

这一点也是我使用forEach比较头疼的，在forEach中的Exception必须要捕获处理，如下代码：

public void testException() throws Exception {

  List<Integer> ids = IntStream.range(1, 4).boxed().collect(Collectors.toList());

  for (int i = 0; i < ids.size(); i++) {

      //直接抛出Exception

      System.out.println(div(i, i - 1));

  }



  ids.stream().forEach(x -> {

      try {

          //必须捕获Exception

          System.out.println(div(x, x - 1));

      } catch (Exception e) {

          throw new RuntimeException(e);

      }

  });

}



private Integer div(Integer a, Integer b) throws Exception {

    return a / b;

}

我们在循环中调用了div()方法，该方法抛出了Exception，如果是使用for循环如果不想处理可以直接抛出，但是使用forEach就必须要自己处理异常了，所以for在处理异常方面会更加灵活方便。

理由六、for能对集合添加、删除

在for循环中可以直接修改原始集合（如添加、删除元素），而 Stream 不允许修改基础集合，会抛出 ConcurrentModificationException，如下代码：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

    if(i<1){

        ids.add(i);

    }

}

System.out.println(ids);



List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2.stream().forEach(x -> {

    if(x<1){

        ids2.add(x);

    }

});

System.out.println(ids2);

输出：

[0, 1, 2, 3, 0]

java.util.ConcurrentModificationException

如果你想在循环中添加或者删除元素foreach是无法完成了，所以for处理集合更方便。

理由七、for Debug更友好

Stream.forEach()使用了Lambda表达示，一行代码可以搞定很多功能，但是这也给Debug带来了困难，如下代码：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

    System.out.println(ids.get(i));

}

List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2.stream().forEach(System.out::println);

以下是DeBug截图：

我们可以看出使用for循环Debug可以一步一步的跟踪程序执行步骤，但是使用forEach却做不到，所以for可以更方便的调试你的代码，让你更快捷的找到出现问题的代码。

理由八、for代码可读性更好

Lambda表达示属于面向函数式编程，主打的就是一个抽象，相比于面向对象或者面向过程编程代码可读性是非常的差，有时自己不写的代码过段时间后自己都看不懂。就比如我在文章《解密阿里大神写的天书般的Tree工具类，轻松搞定树结构！》一文中使用函数式编程写了一个Tree工具类，我们可以对比一下面向过程和面向函数式编程代码可读性的差距：

• 使用for面向过程编程代码：

 public static List<MenuVo> makeTree(List<MenuVo> allDate,Long rootParentId) {

      List<MenuVo> roots = new ArrayList<>();

      for (MenuVo menu : allDate) {

          if (Objects.equals(rootParentId, menu.getPId())) {

              roots.add(menu);

          }

      }

      for (MenuVo root : roots) {

           makeChildren(root, allDate);

      }

      return roots;

  }

  public static MenuVo makeChildren(MenuVo root, List<MenuVo> allDate) {

      for (MenuVo menu : allDate) {

          if (Objects.equals(root.getId(), menu.getPId())) {

              makeChildren(menu, allDate);

              root.getSubMenus().add(menu);

          }

      }

      return root;

  }

• 使用forEach面向函数式编程代码：

public static <E> List<E> makeTree(List<E> list, Predicate<E> rootCheck, BiFunction<E, E, Boolean> parentCheck, BiConsumer<E, List<E>> setSubChildren) {

      return list.stream().filter(rootCheck).peek(x -> setSubChildren.accept(x, makeChildren(x, list, parentCheck, setSubChildren))).collect(Collectors.toList());

}

private static <E> List<E> makeChildren(E parent, List<E> allData, BiFunction<E, E, Boolean> parentCheck, BiConsumer<E, List<E>> children) {

    return allData.stream().filter(x -> parentCheck.apply(parent, x)).peek(x -> children.accept(x, makeChildren(x, allData, parentCheck, children))).collect(Collectors.toList());

}

对比以上两段代码，可以看出面向过程的代码思路非常的清晰，基本上可以一眼看懂代码要做什么，反观面向函数式编程的代码，我想大都人一眼都不知道代码在干什么的，所以使用for的代码可读性会更好。

理由九、for更好的管理状态

for循环可以轻松地在每次迭代中维护状态，这在Stream.forEach中可能需要额外的逻辑来实现。这一条可理由三有点像，我们经常需要通过状态能控制循环是否执行，如下代码：

boolean  flag = true;

for (int i = 0; i < 10; i++) {

    if(flag){

        System.out.println(i);

        flag=false;

    }

}



AtomicBoolean flag1 = new AtomicBoolean(true);

IntStream.range(0, 10).forEach(x->{

    if (flag1.get()){

        flag1.set(false);

        System.out.println(x);

    }

});

这个例子说明了在使用Stream.forEach时，为了维护状态，我们需要引入额外的逻辑，如使用AtomicBoolean，而在for循环中，这种状态管理是直接和简单的。

理由十、for可以使用索引直接访问元素

在某些情况下，特别是当需要根据元素的索引（位置）来操作集合中的元素时，for就可以直接使用索引访问了。在Stream.forEach中就不能直接通过索引访问，比如我们需要将ids中的数字翻倍：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

   ids.set(i,i*2);

}



List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2=ids2.stream().map(x->x*2).collect(Collectors.toList());

我们使用for循环来遍历这个列表，并在每次迭代中根据索引i来修改列表中的元素。这种操作直接且直观。而使用Stream.foreach()不能直接通过索引下标访问元素的，只能将List转换为流，然后使用map操作将每个元素乘以2，最后，我们使用Collectors.toList()将结果收集回一个新的List。

总结

本文介绍了在实际开发中更推荐使用for循环而不是Stream.foreach()来遍历List的十大理由，并给出了具体的代码和测试结果，当然这并不是说就一定要使用传统的for循环，要根据自己的实际情况来选择合适的方法。通过此案件也想让读者明白在互联网世界中你所看到的东西都是别人想让你看到的，这个世界是没有真相的，别人想让你看到的就是所谓的”真相“，做为吃瓜群众一定不能随波逐流，要有鉴别信息真假的能力和培养独立思考的能力。

DTO、BO、PO、VO是什么

在讨论这些是什么的时候，建议先看看我的这篇文章：写好业务代码的经典案例 - 掘金 (juejin.cn)

在上面我的这篇文章中提到的缺乏模型抽象，无边界控制，就是正好对应的DTO BO PO VO这些模型的概念

如何对模型进行抽象，控制边界，可用看看我的这篇文章 ：为啥建议用MapperStruct，不建议用BeanUtils.copyProperties拷贝数据？ - 掘金 (juejin.cn)

在后端开发中，比如传统的MVC架构和现在流行的DDD架构，经常会使用到下列几种对象的概念

• DTO (Data Transfer Object) 数据传输对象： DTO设计模式用于将数据从服务端传输到客户端，或者在不同的服务之间传递。通常，DTO包含了特定业务场景需要的数据结构，并且不包含任何业务逻辑。它简化了不同服务或模块之间的交互，使得各个层之间的耦合度降低。


• BO (Business Object) 业务对象： BO代表了业务逻辑层中的对象，封装了与某个业务相关的数据以及针对这些数据的操作逻辑。一个BO可能由多个实体属性组成，并处理涉及多个实体的复杂业务逻辑。


• PO (Persistent Object) 持久化对象： PO主要用来表示数据库表的一条记录，它的属性和数据库表的字段相对应。通常在持久层（如Hibernate、JPA等ORM框架）中使用，主要用于操作数据库，如保存、更新和查询数据。


• VO (Value Object) 值对象： VO是视图层的对象，通常用于封装展示给用户的数据，它可以和数据库表对应，也可以根据UI界面需求进行定制。VO的主要目的是在页面展示时只携带必要的数据，从而避免把大量不必要的数据暴露给前端。

举个实际代码的例子，这里暂不给出VO，在最后的总结会讲这个VO

• 这个就是PO

@Data

public class User implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;



    private String createTime;



    private String updateTime;



    @TableLogic

    private int isDelete;

}

• UserDTO

@Data

public class UserDTO implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;

}

• UserLoginBO、UserUpdateBO ...

@Data

public class UserLoginBO implements Serializable{

    private String username;



    private String password;

}



@Data

public class UserUpdateBO implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;

}

从上面这个例子大家能看出来区别不

UserDTO是一个大的入口，它可以接收整个模块的参数

BO则是在进入Service层之前对UserDTO的数据进行过滤，并且对边界进行控制

最后在进入infra层之前转为PO

其实BO也可以像UserDTO那样，直接一个UserBO包含UserLoginBO和UserUpdateBO，单纯的做模型转换，不做值过滤也可以

在后端开发中怎么用的

总结

为什么我们通篇没有讲关于VO的事情呢？

我个人的理解是DTO能解决的事情没有必要再加一个VO，我们可以弄一个全局配置，将DTO里面为null值的字段全都过滤掉

这样就没有说将数据传给前端的时候需要加多一个VO

给出代码示例，这样配置就可以把DTO中为null值过滤掉，不会序列化发给前端

@Configuration

public class GlobalConfig extends WebMvcConfigurationSupport {



    @Override

    protected void configureMessageConverters(List<HttpMessageConverter<?>> converters) {

        super.configureMessageConverters(converters);

        converters.add(mappingJackson2HttpMessageConverter());

    }

    /**

     * 自定义mappingJackson2HttpMessageConverter

     * 目前实现：空值忽略，空字段可返回

     */

    private MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter() {

        ObjectMapper objectMapper = new ObjectMapper();

        objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);

        objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);

        return new MappingJackson2HttpMessageConverter(objectMapper);

    }

}

大家好，我是苏三，又跟大家见面了。

前言

很多人刚接触 Spring 的时候，对 @Autowired 绝对是爱得深沉。

一个注解，轻松搞定依赖注入，连代码量都省了。

谁不爱呢？

但慢慢地，尤其是跑到稍微复杂点的项目里，@Autowired 就开始给你整点幺蛾子。

于是，官方Spring 4.0开始：不建议无脑用 @Autowired，而是更推荐构造函数注入。

为什么？

是 @Autowired 不行吗？并不是。

它可以用，但问题是：它不是无敌的，滥用起来容易埋坑。

下面就来聊聊为啥官方建议你慎用 @Autowired，顺便再带点代码例子，希望对你会有所帮助。

苏三最近开源了一个基于 SpringBoot+Vue+uniapp 的商城项目，欢迎访问和star。

1. 容易导致隐式依赖

很多小伙伴在工作中喜欢直接写：

@Service

public class MyService {

    @Autowired

    private MyRepository myRepository;

}

看着挺简单，但问题来了：类的依赖关系藏得太深了。

• 你看这段代码，MyService 和 MyRepository 的关系其实是个“隐形依赖”，全靠 @Autowired 来注入。


• 如果有个同事刚接手代码，打开一看，完全不知道 myRepository 是啥玩意儿、怎么来的，只有通过 IDE 或运行时才能猜出来。

隐式依赖的结果就是，代码看起来简单，但维护起来费劲。

后期加个新依赖，或者改依赖顺序，分分钟把人搞糊涂。

怎么破？

用 构造函数注入 替代。

@Service

public class MyService {

    private final MyRepository myRepository;



    // 构造函数注入，依赖一目了然

    public MyService(MyRepository myRepository) {

        this.myRepository = myRepository;

    }

}

这样做的好处是：

• 依赖清晰： 谁依赖谁，直接写在构造函数里，明明白白。


• 更易测试： 构造函数注入可以手动传入 mock 对象，方便写单元测试。

2. 会导致强耦合

再举个例子，很多人喜欢直接用 @Autowired 注入具体实现类，比如：

@Service

public class MyService {

    @Autowired

    private SpecificRepository specificRepository;

}

表面上没毛病，但这是硬邦邦地把 MyService 和 SpecificRepository 绑死了。

万一有一天，业务改了，需要切换成另一个实现类，比如 AnotherSpecificRepository，你得改代码、改注解，连带着测试也崩。

怎么破？

用接口和构造函数注入，把依赖解耦。

@Service

public class MyService {

    private final Repository repository;



    public MyService(Repository repository) {

        this.repository = repository;

    }

}

然后通过 Spring 的配置文件或者 @Configuration 类配置具体实现：

@Configuration

public class RepositoryConfig {

    @Bean

    public Repository repository() {

        return new SpecificRepository();

    }

}

这么搞的好处是：

• 灵活切换： 改实现类时，不用动核心逻辑代码。


• 符合面向接口编程的思想： 降低耦合，提升可扩展性。

3. 容易导致 NullPointerException

有些小伙伴喜欢这么写：

@Service

public class MyService {

    @Autowired

    private MyRepository myRepository;



    public void doSomething() {

        myRepository.save(); // 啪！NullPointerException

    }

}

问题在哪？如果 Spring 容器还没来得及注入依赖，你的代码就跑了（比如在构造函数或初始化方法中直接调用依赖），结果自然就是 NullPointerException。

怎么破？

用构造函数注入，彻底干掉 null 的可能性。

@Service

public class MyService {

    private final MyRepository myRepository;



    public MyService(MyRepository myRepository) {

        this.myRepository = myRepository; // 确保依赖在对象初始化时就已注入

    }



    public void doSomething() {

        myRepository.save();

    }

}

构造函数注入的另一个优点是：依赖注入是强制的，Spring 容器不给你注入就报错，让问题早暴露。

4.自动装配容易搞出迷惑行为

Spring 的自动装配机制有时候是“黑魔法”，尤其是当你的项目里有多个候选 Bean 时。比如：

@Service

public class MyService {

    @Autowired

    private Repository repository; // 容器里有两个 Repository 实现类，咋办？

}

如果有两个实现类，比如 SpecificRepository 和 AnotherRepository，Spring 容器直接报错。解决方法有两种：

• 指定 @Primary。


• 用 @Qualifier 手动指定。

但这些方式都让代码看起来更复杂了，还可能踩坑。

怎么破？

构造函数注入 + 显式配置。

@Configuration

public class RepositoryConfig {

    @Bean

    public Repository repository() {

        return new SpecificRepository();

    }

}

你明确告诉 Spring 该用哪个实现类，别让容器帮你猜，省得以后“配错药”。

最近就业形势比较困难，为了感谢各位小伙伴对苏三一直以来的支持，我特地创建了一些工作内推群， 看看能不能帮助到大家。

你可以在群里发布招聘信息，也可以内推工作，也可以在群里投递简历找工作，也可以在群里交流面试或者工作的话题。

添加苏三的私人微信：su_san_java，备注：掘金+所在城市，即可加入。

5. 写单元测试非常痛苦

最后，聊聊测试的事儿。

@Autowired 依赖 Spring 容器才能工作，但写单元测试时，大家都不想起 Spring 容器（麻烦、慢）。结果就是：

• 字段注入： 没法手动传入 mock 对象。


• 自动装配： 有时候不清楚用的 Bean 是哪个，测试难搞。

怎么破？

构造函数注入天生就是为单元测试设计的。

public class MyServiceTest {

    @Test

    public void testDoSomething() {

        MyRepository mockRepository = mock(MyRepository.class);

        MyService myService = new MyService(mockRepository);



        // 测试逻辑

    }

}

看见没？

直接传入 mock 对象，测试简单、优雅。

总结

简单总结下问题：

那到底咋办？用 构造函数注入，清晰、稳健、测试友好，官方推荐不是没道理的。

但话说回来，@Autowired 也不是不能用，只是你得分场景。

开发中，养成用构造函数注入的习惯，能让你的代码更健壮，少挖坑，多干活！

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

2024-01-11T21:33:25.233+08:00 ERROR 13212 --- [nio-8080-exec-1] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception



org.springframework.data.redis.serializer.SerializationException: Could not write JSON: Java 8 date/time type `java.time.LocalDateTime` not supported by default: add Module "com.fasterxml.jackson.datatype:jackson-datatype-jsr310" to enable handling (through reference chain: java.util.ArrayList[0]->com.fast.alden.data.model.SysApiResource["createdTime"])

	at org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer.serialize(Jackson2JsonRedisSerializer.java:157) ~[spring-data-redis-3.2.0.jar:3.2.0]

	at org.springframework.data.redis.core.AbstractOperations.rawValue(AbstractOperations.java:128) ~[spring-data-redis-3.2.0.jar:3.2.0]

	at org.springframework.data.redis.core.DefaultValueOperations.set(DefaultValueOperations.java:236) ~[spring-data-redis-3.2.0.jar:3.2.0]

<dependency>

  <groupId>com.fasterxml.jackson.datatypegroupId>

  <artifactId>jackson-datatype-jsr310artifactId>

  <version>2.13.0version>

dependency>

在定义RedisSerializer Bean的代码中自定义ObjectMapper对象处理时间属性时的序列化和反序列化行为，LocalDate、LocalDateTime、LocalTime的序列化和反序列化都要自定义，还要禁用将日期序列化为时间戳。

@Configuration

public class RedisConfig {

    @Bean

    public RedisSerializer

本文已经授权【稀土掘金技术社区】官方公众号独家原创发布。

一、有什么问题吗java.util.Date？

java.util.Date（Date从现在开始）是一个糟糕的类型，这解释了为什么它的大部分内容在 Java 1.1 中被弃用（但不幸的是仍在使用）。

设计缺陷包括：

• 它的名称具有误导性：它并不代表 a Date，而是代表时间的一个瞬间。所以它应该被称为Instant——正如它的java.time等价物一样。


• 它是非最终的：这鼓励了对继承的不良使用，例如java.sql.Date（这意味着代表一个日期，并且由于具有相同的短名称而也令人困惑）


• 它是可变的：日期/时间类型是自然值，可以通过不可变类型有效地建模。可变的事实Date（例如通过setTime方法）意味着勤奋的开发人员最终会在各处创建防御性副本。


• 它在许多地方（包括）隐式使用系统本地时区，toString()这让许多开发人员感到困惑。有关此内容的更多信息，请参阅“什么是即时”部分


• 它的月份编号是从 0 开始的，是从 C 语言复制的。这导致了很多很多相差一的错误。


• 它的年份编号是基于 1900 年的，也是从 C 语言复制的。当然，当 Java 出现时，我们已经意识到这不利于可读性？


• 它的方法命名不明确：getDate()返回月份中的某一天，并getDay()返回星期几。给这些更具描述性的名字有多难？


• 对于是否支持闰秒含糊其辞：“秒由 0 到 61 之间的整数表示；值 60 和 61 仅在闰秒时出现，即使如此，也仅在实际正确跟踪闰秒的 Java 实现中出现。” 我强烈怀疑大多数开发人员（包括我自己）都做了很多假设，认为 for 的范围getSeconds()实际上在 0-59 范围内（含）。


• 它的宽容没有明显的理由：“在所有情况下，为这些目的而对方法给出的论据不必落在指定的范围内; 例如，日期可以指定为 1 月 32 日，并被解释为 2 月 1 日。” 多久有用一次？

原文如下：为什么要避免使用Date类？

二、为啥要改？

我们要改的原因很简单，我们的代码缺陷扫描规则认为这是一个必须修改的缺陷，否则不给发布，不改不行，服了。

解决思路：避免使用java.util.Date与java.sql.Date类和其提供的API，考虑使用java.time.Instant类或java.time.LocalDateTime类及其提供的API替代。

三、怎么改？

只能说这种基础的类改起来牵一发动全身，需要从DO实体类看起，然后就是各种Converter，最后是DTO。由于我们还是微服务架构，业务服务依赖于基础服务的API，所以必须要一起改否则就会报错。这里就不细说修改流程了，主要说一下我们在改造的时候遇到的一些问题。

1. 耐心比对数据库日期字段和DO的映射

（1）确定字段类型

首先你需要确定数据对象中的 Date 字段代表的是日期、时间还是时间戳。

• 如果字段代表日期和时间，则可能需要使用 LocalDateTime。


• 如果字段仅代表日期，则可能需要使用 LocalDate。


• 如果字段仅代表时间，则可能需要使用 LocalTime。


• 如果字段需要保存时间戳（带时区的），则可能需要使用 Instant 或 ZonedDateTime。

（2）更新数据对象类

更新数据对象类中的字段，把 Date 类型改为适当的 java.time 类型。

2. 将DateUtil中的方法改造

（1）替换原来的new Date()和Calendar.getInstance().getTime()

原来的方式:

Date nowDate = new Date();

Date nowCalendarDate = Calendar.getInstance().getTime();

使用 java.time 改造后:

// 使用Instant代表一个时间点，这与Date类似

Instant nowInstant = Instant.now();



// 如果需要用到具体的日期和时间（例如年、月、日、时、分、秒）

LocalDateTime nowLocalDateTime = LocalDateTime.now();



// 如果你需要和特定的时区交互，可以使用ZonedDateTime

ZonedDateTime nowZonedDateTime = ZonedDateTime.now();



// 如果你需要转换回java.util.Date，你可以这样做（假设你的代码其他部分还需要使用Date）

Date nowFromDateInstant = Date.from(nowInstant);



// 如果需要与java.sql.Timestamp交互

java.sql.Timestamp nowFromInstant = java.sql.Timestamp.from(nowInstant);

一些注意点:

（2）一些基础的方法改造

a. dateFormat

原来的方式

public static String dateFormat(Date date, String dateFormat) {

    SimpleDateFormat formatter = new SimpleDateFormat(dateFormat);

    return formatter.format(date);

}

使用java.time改造后

public static String dateFormat(LocalDateTime date, String dateFormat) {

    DateTimeFormatter formatter = DateTimeFormatter.ofPattern(dateFormat);

    return date.format(formatter);

}

b. addSecond、addMinute、addHour、addDay、addMonth、addYear

原来的方式

public static Date addSecond(Date date, int second) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(13, second);

    return calendar.getTime();

}



public static Date addMinute(Date date, int minute) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(12, minute);

    return calendar.getTime();

}



public static Date addHour(Date date, int hour) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(10, hour);

    return calendar.getTime();

}



public static Date addDay(Date date, int day) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(5, day);

    return calendar.getTime();

}



public static Date addMonth(Date date, int month) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(2, month);

    return calendar.getTime();

}



public static Date addYear(Date date, int year) {

    Calendar calendar = Calendar.getInstance();

    calendar.setTime(date);

    calendar.add(1, year);

    return calendar.getTime();

}

使用java.time改造后

public static LocalDateTime addSecond(LocalDateTime date, int second) {

    return date.plusSeconds(second);

}



public static LocalDateTime addMinute(LocalDateTime date, int minute) {

    return date.plusMinutes(minute);

}



public static LocalDateTime addHour(LocalDateTime date, int hour) {

    return date.plusHours(hour);

}



public static LocalDateTime addDay(LocalDateTime date, int day) {

    return date.plusDays(day);

}



public static LocalDateTime addMonth(LocalDateTime date, int month) {

    return date.plusMonths(month);

}



public static LocalDateTime addYear(LocalDateTime date, int year) {

    return date.plusYears(year);

}

c. dateToWeek

原来的方式

public static final String[] WEEK_DAY_OF_CHINESE = new String[]{"周日", "周一", "周二", "周三", "周四", "周五", "周六"};

public static String dateToWeek(Date date) {

    Calendar cal = Calendar.getInstance();

    cal.setTime(date);

    return WEEK_DAY_OF_CHINESE[cal.get(7) - 1];

}

使用java.time改造后

public static final String[] WEEK_DAY_OF_CHINESE = new String[]{"周日", "周一", "周二", "周三", "周四", "周五", "周六"};



public static String dateToWeek(LocalDate date) {

    DayOfWeek dayOfWeek = date.getDayOfWeek();

    return WEEK_DAY_OF_CHINESE[dayOfWeek.getValue() % 7];

}

d. getStartOfDay和getEndOfDay

原来的方式

public static Date getStartTimeOfDay(Date date) {

    if (date == null) {

        return null;

    } else {

        LocalDateTime localDateTime = LocalDateTime.ofInstant(Instant.ofEpochMilli(date.getTime()), ZoneId.systemDefault());

        LocalDateTime startOfDay = localDateTime.with(LocalTime.MIN);

        return Date.from(startOfDay.atZone(ZoneId.systemDefault()).toInstant());

    }

}



public static Date getEndTimeOfDay(Date date) {

    if (date == null) {

        return null;

    } else {

        LocalDateTime localDateTime = LocalDateTime.ofInstant(Instant.ofEpochMilli(date.getTime()), ZoneId.systemDefault());

        LocalDateTime endOfDay = localDateTime.with(LocalTime.MAX);

        return Date.from(endOfDay.atZone(ZoneId.systemDefault()).toInstant());

    }

}

使用java.time改造后

public static LocalDateTime getStartTimeOfDay(LocalDateTime date) {

    if (date == null) {

        return null;

    } else {

        // 获取一天的开始时间，即00:00

        return date.toLocalDate().atStartOfDay();

    }

}



public static LocalDateTime getEndTimeOfDay(LocalDateTime date) {

    if (date == null) {

        return null;

    } else {

        // 获取一天的结束时间，即23:59:59.999999999

        return date.toLocalDate().atTime(LocalTime.MAX);

    }

}

e. betweenStartAndEnd

原来的方式

public static Boolean betweenStartAndEnd(Date nowTime, Date beginTime, Date endTime) {

    Calendar date = Calendar.getInstance();

    date.setTime(nowTime);

    Calendar begin = Calendar.getInstance();

    begin.setTime(beginTime);

    Calendar end = Calendar.getInstance();

    end.setTime(endTime);

    return date.after(begin) && date.before(end);

}

使用java.time改造后

public static Boolean betweenStartAndEnd(Instant nowTime, Instant beginTime, Instant endTime) {

    return nowTime.isAfter(beginTime) && nowTime.isBefore(endTime);

}

我这里就只列了一些，如果有缺失的可以自己补充，不会写的话直接问问ChatGPT，它最会干这事了。最后把这些修改后的方法替换一下就行了。

四、小结一下

这个改造难度不高，但是复杂度非常高，一个地方没改好，轻则接口报错，重则启动失败，非常耗费精力，真不想改。

文末小彩蛋，自建摸鱼网站，各大网站热搜一览，上班和摸鱼很配哦！

众所周知，上个月的时候，GitHub 知名开源项目 EasyExcel 曾对外发布公告将停止主动更新，当时这个消息在网上还引发了不少讨论。

至此，这个运营了 6 年，在 GitHub 上累计收获 32k+ star 的知名项目基本就宣告停更了，大家都觉得挺可惜的。

然而，就在阿里官宣停更的同时，EasyExcel 的原作者个人当即也站出来向大家透露了一个新项目计划，表示自己将会继续接手，并重启一个新项目开源出来。

那现在，这个承诺已经如期兑现了！

就在上周，EasyExcel 作者自己也正式发文表示，EasyExcel 的替代方案正式来了，相信不少同学也看到了这个消息。

作者把新项目定名为：FastExcel（ps：作者一开始初定叫 EasyExcel-Plus，后来改名为了 FastExcel），用于取代已经被阿里官方停更的 EasyExcel 项目。

新项目 FastExcel 同样定位在一个基于 Java 的、快速、简洁、解决大文件内存溢出的 Excel 处理工具。

并且新项目将兼容老的已停更的 EasyExcel 项目，并提供项目维护、性能优化、以及bugFix。

同时作者还表示，新项目 FastExcel 将始终坚持免费开源，并采用最开放的 MIT 协议，使其适用于任何商业化场景，以便为广大开发者和企业继续提供极大的自由度和灵活性。

不得不说，作者的格局还是相当打开的。

大家都知道，其实 EasyExcel 项目的作者原本就是工作在阿里，负责主导并维护着这个项目。

然而就在去年，Easyexcel 作者就从阿里离职出来创业了。

所以在上个月 EasyExcel 被宣布停更的时候，当时就有不少网友猜测各种原因。当然背后的真相我们不得而知，不过作为用户的角度来看，Easyexcel 以另外一种形式被继续开源和更新也何尝不是一件利好用户的好消息。

之前的 EasyExcel 之所以受到开发者们的广泛关注，主要是因为它具备了许多显著的特点和优势，而这次的新项目 FastExcel 更可谓是有过之而无不及。

• 首先，FastExcel 同样拥有卓越的读写性能，能够高效地处理大规模的Excel数据，这对于需要处理大量数据的开发者来说依然是一大福音。


• 其次，FastExcel 的 API设计简洁直观，开发者可以轻松上手，无需花费大量时间学习和熟悉。


• 再者，FastExcel 同样支持流式读取，可以显著降低内存占用，避免在处理大规模数据时可能出现的内存溢出问题。


• 此外，新项目 FastExcel 完全兼容原来 EasyExcel 的功能和特性，用户可以在项目中无缝过渡，从 EasyExcel 迁移到 FastExcel 只需更换包名和依赖即可完成升级。

FastExcel 的安装配置也非常简单。

对于使用 Maven 或 Gradle 进行构建的项目来说，只需在相应的配置文件中添加如下所示的 FastExcel 的依赖即可。

• Maven项目

<dependency>

    <groupId>cn.idev.excel</groupId>

    <artifactId>fastexcel</artifactId>

    <version>1.0.0</version>

</dependency>

• Gradle项目

dependencies {

    implementation 'cn.idev.excel:fastexcel:1.0.0'

}

在实际使用中，以读取Excel文件为例，开发者只需定义一个数据类和一个监听器类，然后在主函数中调用 FastExcel 的读取方法，并传入数据类和监听器类即可。

FastExcel 会自动解析 Excel 文件中的数据，并将其存储到数据类的实例中，同时触发监听器类中的方法，让开发者可以对解析到的数据进行处理。

// 实现 ReadListener 接口，设置读取数据的操作

public class DemoDataListener implements ReadListener<DemoData> {

    @Override

    public void invoke(DemoData data, AnalysisContext context) {

        System.out.println("解析到一条数据" + JSON.toJSONString(data));

    }



    @Override

    public void doAfterAllAnalysed(AnalysisContext context) {

        System.out.println("所有数据解析完成！");

    }

}



public static void main(String[] args) {

    String fileName = "demo.xlsx";

    // 读取 Excel 文件

    FastExcel.read(fileName, DemoData.class, new DemoDataListener()).sheet().doRead();

}

同样地，写 Excel 文件也非常简单，开发者只需定义一个数据类，并填充要写入的数据，然后调用 FastExcel 的写入方法即可。

// 示例数据类

public class DemoData {

    @ExcelProperty("字符串标题")

    private String string;

    @ExcelProperty("日期标题")

    private Date date;

    @ExcelProperty("数字标题")

    private Double doubleData;

    @ExcelIgnore

    private String ignore;

}



// 填充要写入的数据

private static List<DemoData> data() {

    List<DemoData> list = new ArrayList<>();

    for (int i = 0; i < 10; i++) {

        DemoData data = new DemoData();

        data.setString("字符串" + i);

        data.setDate(new Date());

        data.setDoubleData(0.56);

        list.add(data);

    }

    return list;

}



public static void main(String[] args) {

    String fileName = "demo.xlsx";

    // 创建一个名为“模板”的 sheet 页，并写入数据

    FastExcel.write(fileName, DemoData.class).sheet("模板").doWrite(data());

}

过程可谓是清晰易懂、直观明了，所以这对于开发者来说，在使用 FastExcel 时可以轻松上手。

新项目 FastExcel 刚开源不久，目前在 GitHub 上的 star 标星就已经突破了 2000！这也可见其受欢迎程度。

而且伴随着新项目的开源上线，开发者们的参与热情也是十分高涨的。

这才多少天，项目就已经收到上百条issue了。

仔细看了一下会发现，其中一大部分是开发者们对于新项目所提的需求或反馈。

而还有另外一部分则是对于新项目 FastExcel 以及作者的肯定与鼓励。

文章的最后也感谢项目作者的辛勤维护，大家有需要的话也可以上去提需求或者反馈一些意见，另外感兴趣的同学也可以上去研究研究相关的代码或者参与项目，尤其是数据处理这一块，应该会挺有收获的。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

前言

在 Java 开发的征途中，我们时常与重复代码不期而遇。这些重复代码不仅让项目显得笨重，更增加了维护成本。幸运的是，Java 8 带来了函数式编程的春风，以 Function 接口为代表的一系列新特性，为我们提供了破除这一难题的利剑。本文将以一个实际应用场景为例，即使用 Java 8 的函数式编程特性来重构数据有效性断言逻辑，展示如何通过 SFunction（基于 Java 8 的 Lambda 表达式封装）减少代码重复，从而提升代码的优雅性和可维护性。

背景故事：数据校验的烦恼

想象一下，在一个复杂的业务系统中，我们可能需要频繁地验证数据库中某个字段值是否有效，是否符合预期值。传统的做法可能充斥着大量相似的查询逻辑，每次都需要手动构建查询条件、执行查询并处理结果，这样的代码既冗长又难以维护。

例如以下两个验证用户 ID 和部门 ID 是否有效的方法，虽然简单，但每次需要校验不同实体或不同条件时，就需要复制粘贴并做相应修改，导致代码库中充满了大量雷同的校验逻辑，给维护带来了困扰。

// 判断用户 ID 是否有效

public void checkUserExistence(String userId) {

    User user = userDao.findById(userId);

    if (user == null) {

        throw new RuntimeException("用户ID无效");

    }

}



// 判断部门 ID 是否有效

public void checkDeptExistence(String deptId) {

    Dept dept = deptDao.findById(deptId);

    if (dept == null) {

        throw new RuntimeException("部门ID无效");

    }   

}

Java 8 的魔法棒：函数式接口

Java 8 引入了函数式接口的概念，其中 Function<T, R> 是最基础的代表，它接受一个类型 T 的输入，返回类型 R 的结果。而在 MyBatis Plus 等框架中常用的 SFunction 是对 Lambda 表达式的进一步封装，使得我们可以更加灵活地操作实体类的属性。

实战演练：重构断言方法

下面的 ensureColumnValueValid 方法正是利用了函数式接口的魅力，实现了对任意实体类指定列值的有效性断言：

/**

 * 确认数据库字段值有效（通用）

 * 

 * @param <V> 待验证值的类型

 * @param valueToCheck 待验证的值

 * @param columnExtractor 实体类属性提取函数

 * @param queryExecutor 单条数据查询执行器

 * @param errorMessage 异常提示信息模板

 */

public static <T, R, V> void ensureColumnValueValid(V valueToCheck, SFunction<T, R> columnExtractor, SFunction<LambdaQueryWrapper<T>, T> queryExecutor, String errorMessage) {

    if (valueToCheck == null) return;

    

    LambdaQueryWrapper<T> wrapper = new LambdaQueryWrapper<>();

    wrapper.select(columnExtractor);

    wrapper.eq(columnExtractor, valueToCheck);

    wrapper.last("LIMIT 1");



    T entity = queryExecutor.apply(wrapper);

    R columnValue = columnExtractor.apply(entity);

    if (entity == null || columnValue == null)

        throw new DataValidationException(String.format(errorMessage, valueToCheck));

}

这个方法接受一个待验证的值、一个实体类属性提取函数、一个单行数据查询执行器和一个异常信息模板作为参数。通过这四个参数，不仅能够进行针对特定属性的有效性检查，而且还能生成具有一致性的异常信息。

对比分析

使用 Function 改造前

// 判断用户 ID 是否有效

public void checkUserExistence(String userId) {

    User user = userDao.findById(userId);

    if (user == null) {

        throw new RuntimeException("用户ID无效");

    }

}



// 判断部门 ID 是否有效

public void checkDeptExistence(String deptId) {

    Dept dept = deptDao.findById(deptId);

    if (dept == null) {

        throw new RuntimeException("部门ID无效");

    }   

}

使用 Function 改造后

public void assignTaskToUser(AddOrderDTO dto) {

    ensureColumnValueValid(dto.getUserId(), User::getId, userDao::getOne, "用户ID无效");

    ensureColumnValueValid(dto.getDeptId(), Dept::getId, deptDao::getOne, "部门ID无效");    

    ensureColumnValueValid(dto.getCustomerId(), Customer::getId, customerDao::getOne, "客户ID无效");

    ensureColumnValueValid(dto.getDeptId(), Dept::getId, deptDao::getOne, "部门ID无效");

    ensureColumnValueValid(dto.getSupplieId(), Supplie::getId, supplierDao::getOne, "供应商ID无效");



    // 现在可以确信客户存在

    Customer cus = customerDao.findById(dto.getCustomerId());     

    

    // 创建订单的逻辑...

}

对比上述两段代码，我们发现后者不仅大幅减少了代码量，而且通过函数式编程，表达出更为清晰的逻辑意图，可读性和可维护性都有所提高。

优点

举一反三：拓展校验逻辑的边界

通过上述的实践，我们见识到了函数式编程在简化数据校验逻辑方面的威力。但这只是冰山一角，我们可以根据不同的业务场景，继续扩展和完善校验逻辑，实现更多样化的校验需求。以下两个示例展示了如何在原有基础上进一步深化，实现更复杂的数据比较和验证功能。

断言指定列值等于预期值

首先，考虑一个场景：除了验证数据的存在性，我们还需确认查询到的某列值是否与预期值相符。这在验证用户角色、状态变更等场景中尤为常见。为此，我们设计了 validateColumnValueMatchesExpected 方法：

/**

 * 验证查询结果中指定列的值是否与预期值匹配

 *

 * @param <T>             实体类型

 * @param <R>             目标列值的类型

 * @param <C>             查询条件列值的类型

 * @param targetColumn    目标列的提取函数，用于获取想要验证的列值

 * @param expectedValue   期望的列值

 * @param conditionColumn 条件列的提取函数，用于设置查询条件

 * @param conditionValue  条件列对应的值

 * @param queryMethod     执行查询的方法引用，返回单个实体对象

 * @param errorMessage    验证失败时抛出异常的错误信息模板

 * @throws RuntimeException 当查询结果中目标列的值与预期值不匹配时抛出异常

 */

public static <T, R, C> void validateColumnValueMatchesExpected(

      SFunction<T, R> targetColumn, R expectedValue,

      SFunction<T, C> conditionColumn, C conditionValue,

      SFunction<LambdaQueryWrapper<T>, T> queryMethod,

      String errorMessage) {



   // 创建查询包装器，选择目标列并设置查询条件

   LambdaQueryWrapper<T> wrapper = new LambdaQueryWrapper<>();

   wrapper.select(targetColumn);

   wrapper.eq(conditionColumn, conditionValue);



   // 执行查询方法

   T one = queryMethod.apply(wrapper);

   // 如果查询结果为空，则直接返回，视为验证通过（或忽略）

   if (one == null) return;



   // 获取查询结果中目标列的实际值

   R actualValue = targetColumn.apply(one);



   // 比较实际值与预期值是否匹配，这里假设notMatch是一个自定义方法用于比较不匹配情况

   boolean doesNotMatch = notMatch(actualValue, expectedValue);

   if (doesNotMatch) {

      // 若不匹配，则根据错误信息模板抛出异常

      throw new RuntimeException(String.format(errorMessage, expectedValue, actualValue));

   }

}



// 假设的辅助方法，用于比较值是否不匹配，根据实际需要实现

private static <R> boolean notMatch(R actual, R expected) {

    // 示例简单实现为不相等判断，实际情况可能更复杂

    return !Objects.equals(actual, expected);

}

这个方法允许我们指定一个查询目标列（targetColumn）、预期值（expectedValue）、查询条件列（conditionColumn）及其对应的条件值（conditionValue），并提供一个查询方法（queryMethod）来执行查询。如果查询到的列值与预期不符，则抛出异常，错误信息通过 errorMessage 参数定制。

应用场景：
例如在一个权限管理系统中，当需要更新用户角色时，系统需要确保当前用户的角色在更新前是 “普通用户”，才能将其升级为 “管理员”。此场景下，可以使用 validateColumnValueMatchesExpected 方法来验证用户当前的角色是否确实为“普通用户”。

// 当用户角色不是 “普通用户” 时抛异常

validateColumnValueMatchesExpected(User::getRoleType, "普通用户", User::getId, userId, userMapper::getOne, "用户角色不是普通用户，无法升级为管理员！");

断言指定值位于期望值列表内

进一步，某些情况下我们需要验证查询结果中的某一列值是否属于一个预设的值集合。例如，验证用户角色是否合法。为此，我们创建了 validateColumnValueMatchesExpectedList 方法：

/**

 * 验证查询结果中指定列的值是否位于预期值列表内

 *

 * @param <T>             实体类型

 * @param <R>             目标列值的类型

 * @param <C>             查询条件列值的类型

 * @param targetColumn    目标列的提取函数，用于获取想要验证的列值

 * @param expectedValueList 期望值的列表

 * @param conditionColumn 条件列的提取函数，用于设置查询条件

 * @param conditionValue  条件列对应的值

 * @param queryMethod     执行查询的方法引用，返回单个实体对象

 * @param errorMessage    验证失败时抛出异常的错误信息模板

 * @throws RuntimeException 当查询结果中目标列的值不在预期值列表内时抛出异常

 */

public static <T, R, C> void validateColumnValueInExpectedList(

        SFunction<T, R> targetColumn, List<R> expectedValueList,

        SFunction<T, C> conditionColumn, C conditionValue,

        SFunction<LambdaQueryWrapper<T>, T> queryMethod,

        String errorMessage) {



    LambdaQueryWrapper<T> wrapper = new LambdaQueryWrapper<>();

    wrapper.select(targetColumn);

    wrapper.eq(conditionColumn, conditionValue);



    T one = queryMethod.apply(wrapper);

    if (one == null) return;



    R actualValue = targetColumn.apply(one);

    if (actualValue == null) throw new RuntimeException("列查询结果为空");



    if (!expectedValueList.contains(actualValue)) {        

        throw new RuntimeException(errorMessage);

    }

}

这个方法接受一个目标列（targetColumn）、一个预期值列表（expectedValueList）、查询条件列（conditionColumn）及其条件值（conditionValue），同样需要一个查询方法（queryMethod）。如果查询到的列值不在预期值列表中，则触发异常。

应用场景： 在一个电商平台的订单处理流程中，系统需要验证订单状态是否处于可取消的状态列表里（如 “待支付”、“待发货”）才允许用户取消订单。此时，validateColumnValueInExpectedList 方法能有效确保操作的合法性。

// 假设 OrderStatusEnum 枚举了所有可能的订单状态，cancelableStatuses 包含可取消的状态

List<String> cancelableStatuses = Arrays.asList(OrderStatusEnum.WAITING_PAYMENT.getValue(), OrderStatusEnum.WAITING_DELIVERY.getValue());



// 验证订单状态是否在可取消状态列表内

validateColumnValueInExpectedList(Order::getStatus, cancelableStatuses, Order::getOrderId, orderId, orderMapper::selectOne, "订单当前状态不允许取消！");

通过这两个扩展方法，我们不仅巩固了函数式编程在减少代码重复、提升代码灵活性方面的优势，还进一步证明了通过抽象和泛型设计，可以轻松应对各种复杂的业务校验需求，使代码更加贴近业务逻辑，易于理解和维护。

核心优势

函数式编程的力量

通过这个实例，我们见证了函数式编程在简化代码、提高抽象层次上的强大能力。在 Java 8 及之后的版本中，拥抱函数式编程思想，不仅能够使我们的代码更加简洁、灵活，还能在一定程度上促进代码的正确性和可测试性。因此，无论是日常开发还是系统设计，都值得我们深入探索和应用这一现代编程范式，让代码如魔法般优雅而高效。

一、前言

三维GIS是一个伪概念,GIS是地理信息系统，三维GIS就是三维地理信息系统，在课本上，专业概念上，也没有这一说法吧，所以三维GIS，就是技术人员造概念拼凑造出来的，本质上就是GIS三维可视化。

二、详细介绍

GIS从广义层面分为两大方面，第一是数据及数据管理，第二是业务功能，其中业务，就是分析、显示、交互。按照云计算服务划分，分别对应着DAAS层和SAAS层。按照所谓三维GIS的说法，那就是三维数据管理、三维分析、三维显示、三维交互。目前三维GIS基本上就是围绕着三维数据、三维分析、三维数据显示以及三维交互这四方面展开，其中三维数据是主要表现力。

1.三维数据

三维GIS场景与游戏场景的最主要也是最本质区别在于，三维GIS的数据都是真实的，来源于真实世界映射数据，包括卫星影像、三维地形DEM/DSM/DTM、倾斜摄影、点云等各式各样数据。游戏场景绝大部分人工建模出来的理想中的场景。一个是面向现实，一个面向未来，如果把两者结合，是不是有“元宇宙”的味道了呢？

2.三维分析

三维分析，即基于三维数据进行的分析计算，三维即三维空间，三维空间的GIS分析，三维空间距离量算、三维体积量算、三维高度量算……本质上应该比二维分析更丰富才对。可惜的是，三维空间分析，绝大部分在课本上找不到，更别说概念化描述。

3.三维可视化

三维可视化绝大部分是三维数据的可视化，我们常见的有地形可视化、倾斜摄影可视化

4.三维交互

除了普通的漫游、缩放、旋转、更有俯仰、翻转等操作。从上面可以看出三维GIS重点还是在于可视化，做三维GIS可视化，两大核心是GIS+图形学。想要在三维GIS深耕，就需要在计算机图形学有很好的基础，较强的GIS开发概念，以及自己的想象力。而图形学是公认的成长缓慢的大后期，比C++成长更慢，更别说与Java、JavaScript等相提并论。因此以后把三维GIS作为自己的就业方向，前景很光明，即使以后不在GIS圈，去互联网游戏行业都能胜任，而且比纯游戏开发更有优势。

三、结语

目前GIS公司对三维GIS的开发需求很强烈，但是受限于大学所学，能在大学既能懂GIS又懂图形学的，凤毛麟角，所以三维GIS开发很抢手，但是学校都找不到人，绝大部分都是招来基础好的学生，从零开始培养。

学好三维GIS，不仅仅会一个Cesium、MapBox就完了，这最初级阶段，只是二次开发，熟悉了接口，你就需要从原理角度去熟悉底层原理，渲染管线、地形瓦片及3dtiles调度与渲染等等，这些都需要你去认真深入学习的，还有一点，也是很三维GIS的最重要的一件武器:shader。这是必须熟练掌握的，包括glsl，hlsl等。

最后，就是要学游戏引擎，目前，做三维GIS与游戏引擎结合的越来越紧密，随着信创产业的快速发展，UE以后会越来越得到应用，做三维GIS，离不开熟练使用UE或者Unity。以上是我个人的一些看法，希望看到有更多的人投入到三维GIS中去，创造越来越多很酷的三维GIS产品，服务社会，造福人类！