思考，输出，沉淀。用通俗的语言陈述技术，让自己和他人都有所收获。

作者：毅航😜

在SpringBoot应用开发中，利用@ControllerAdvice 结合 @ExceptionHandler来实现对后端服务的统一异常管理似乎已经成为了开发者约定俗成的规范了，为此网上也有很多文章来阐述如何更加优雅的来实现统一异常管理，但这样做真的好吗?

前言

在SpringBoot中的全局统一异常管理通常是指利用@ControllerAdvice 结合 @ExceptionHandler来自定义一个全局的异常处理器，从而避免了在程序中频繁写书写try-catch来对异常进行处理。但结合笔者最近惨痛debug旧有项目的经历来看，笔者不推荐这样去做。

在讨论之前我们不妨先来看看实际开发中都有哪些地方可能出现的异常。

全局异常所带来的困惑

目前，大部分应用在开发时，通常会将代码划分为控制层，服务层，数据访问层三层结构，每个模块负责自己独立的逻辑。简单来看，控制层主要作用在于对外暴露 ur1访问地址，并将前台的处理请求委托给服务层来处理;而对于服务层来说其主要是业务逻辑处理的地方，以登录请求为例，用户名、密码的校验通常会放在服务层来处理;数据访问层则主要用于对数据库进行访问。如下这张图直观的反映了三层架构下各个模块所肩负的责任。

知晓了软件开发过程中的分层架构模式后。我们再来看每个模块可能产生的异常信息。其中：

• 控制层主要用于处理实现前后端交互逻辑，其主要负责信息收禁、参数校验等，抛出的异常也多是参数校验、请求服务异常等异常信息。


• 服务层主要用于处理业务逻辑，以及各种外部服务调用、访问数据作、缓存处理、消息处理等处理操作，这部分可能抛出的逻辑就非常多了。例如，数据库访问异常、服务调用异常等问题。


• 数据访问层则主要负责数据访问实现，其一般没有业务逻辑。由于目前持久层使用技术通常为Mybatis，所以这一层抛出的异常多是Mybatis框架内部所抛出的异常。

不难发现，其中每一层所抛出的异常类型有着很大的差异。而我们在使用全局异常管理时，通常使用如下
代码逻辑：

@ControllerAdvice

public class GlobalExceptionHandler {



    @ExceptionHandler(Exception.class)

    public ResponseEntity<String> handleGlobalException(Exception ex) {

        // 在这里实现异常处理逻辑

       log.error(ex.getMessage());//在控制台打印错误信息

       return Result.error(ex.getMessage());

    }

}



  

即我们通过在ExceptionHandler执行捕获异常为Exception来尽可能捕获业务中可能遇到的各种异常，相信网上已经有很多博主都在不断讲授这样的写法。

但这样做真的好吗？在笔者最近接手的旧项目中，当后端无法处理前端请求后会返回如下信息：

{

   "message": “服务器异常”,

   "code":602

}

而后台服务通常会打印出如下信息：

（注：此处仅为展示，真实环境出现的异常远比此复杂）

不难发现，通过网上所盛传全局异常处理逻辑，我根本不知道问题出在哪里。我只知道当前程序出现异常，且异常信息为/ by zero。除此之外我无法得到任何有用的信息。

此外，通过在@ExceptionHandler配置Exception.class使得程序可以捕获多种异常信息，但这样粗粒度做法所导致的直接问题就是无法精确的定位异常问题发生所在地，极大的提升了问题定位的难度。以笔者项目同事debug经历来看，当项目无法正常运行时，组内的程序员通常会通过打日志的方法来一行一行定位问题所在。

破解之道

其实造成这样调试困难得本质原因在于全局异常机制的滥用，如下这张图真实的反映了引入全局异常机制后，异常的处理逻辑。

不难发现，当引入全局异常处理后，所有的异常信息都会交由RestExceptionHandler来进行处理。当程序遇到异常时，会将异常信息抛给RestExceptionHandler来处理，并由其定义错误的处理逻辑。

分析到此处，其实你已经发现了。对于全局异常处理逻辑而言，其更适合做异常的兜底工作。即如果当前层出现异常，并且不断上抛的仍然无法解决的话，不妨通过全局统一的异常管理来进行处理，以对这些未处理的异常进行捕获。

此外，异常处理不应该进行像很多博客说的那样，仅是通过e.getMessage打印异常信息就可以了。这对于排查问题没有以一丁点的帮助，可以说是百害而无一利。

对于此，笔者更推荐在打印异常信息时，记录异常以及当前 URL、执行方法等信息以便后期方便问题排查。具体可参考如下代码：

@Slf4j

@RestControllerAdvice

public class GlobExceptionHandler {





    @ExceptionHandler(ArithmeticException.class)//ArithmeticException异常类型通过注解拿到

    public String exceptionHandler(HttpServletRequest request,ArithmeticException exception){

       // 打印详细信息

        log(request,exception);

        return exception.getMessage();



    }





    public void log(HttpServletRequest request, Exception exception) {

        //换行符

        String lineSeparatorStr = System.getProperty("line.separator");



        StringBuilder exStr = new StringBuilder();

        StackTraceElement[] trace = exception.getStackTrace();

        // 获取堆栈信息并输出为打印的形式

        for (StackTraceElement s : trace) {

            exStr.append("\tat " + s + "\r\n");

        }

        //打印error级别的堆栈日志

        log.error("访问地址：" + request.getRequestURL() + ",请求方法：" + request.getMethod() +

                ",远程地址：" + request.getRemoteAddr() + lineSeparatorStr +

                "错误堆栈信息如下:" + exception.toString() + lineSeparatorStr + exStr);

    }

}

当程序发生错误时，其打印的日志信息如下：

不难发现，其完整的打印出了url、方法信息，错误参数、请求地址等信息，极大的降低了线上Bug的排查难度。

总结

技术本身并没有什么对与错之分，只不过有时我们用的方式和时机不对，进而使得本该提效的工具，反而在不断拖垮我们的效率。就如同本文分析的全局异常处理机制一样，其确实可以帮助我们降低try-catch的使用，但错误且不加考虑的乱用只会使得当系统出现问题时，我们只能两眼一抹黑，然后一行一行打日志来定位问题。

最后，对于代码中异常的捕获处理，笔者认为全局异常应该作为异常处理的都兜底操作，而不应该成为异常处理的灵丹妙药！ 此外，全局异常处理过程不应该仅是简单的 e.getMessage()打印异常消息即可，其更应记录更加有助于异常排查的信息例如，方法，请求的url，请求参数等信息。

如果觉文章对你有帮助，不妨点赞+关注，不错过笔者之后的每一次更新！

背景

toB 的本地化 java 应用程序，通常是部署在客户机器上，为了保护知识产权，我们需要将核心代码（例如 Lience，Billing，Pay 等）进行加密或混淆，防止使用 jadx 等工具轻易反编译。同时，为了更深层的保护程序，也要防止三方依赖细节被窥探；

业界方案

思考：

我们的需求到底是什么？a：保护知识产权。具体手段为：

但上面的几个项目，基本都是围绕着 class 加密(除了GraalVM)，这无法实现我们的第二个需求。

我们的方案

设计目标：

设计方案：

逻辑如下：

注意点：

End

通过以上方案，我们实现了一个极其轻量的 maven 加密，agent 解密插件。他能够将三方包彻底加密，使 jadx 等工具无法反编译 ，屏蔽我们的三方依赖细节，同时，该插件也可以加密我们的业务 class 代码，使 jadx 无法反编译运行时生成的代码，从而一定程度的保护我们的知识产权；

另外，私有的加密算法，在性能，体积，内存等方便的影响都控制在 5% 以内。

为了防止混淆后的代码影响 arthas 的使用和 bug patch 的应用，我们放弃了混淆方案，只能说是一种权衡与取舍吧。

从软件防破解的角度来理解，通常只能是加大破解的难度，铁了心想要破解的话，就算是 ProGuard 混淆，也无法解决。也许只能用 GraalVM，但不是每一个客户都会用这个。

推荐

Java 扩展点/插件系统，支持热插拔，旨在解决大部分软件的功能定制问题

1. 背景

随着越来越多的公司拥抱云原生，从原先的单体应用演变为微服务，应用的部署方式也从虚机变为容器化，容器编排组件k8s也成为大多数公司的标配。然而在容器化以后，我们发现应用的性能比原先在虚拟机上表现更差，这是为什么呢？。

2. 压测结果

2.1 容器化之前的表现

应用部署在虚拟机下，我们使用wrk工具进行压测，压测结果如下：

从压测结果看，$\color{red}{平均RT为1.68ms，qps为716/s}$，我们再来看下机器的资源使用情况，cpu基本已经被打满。

2.2 容器化后的表现

使用wrk工具进行压测，结果如下：

从压测结果看，$\color{red}{平均RT为2.11ms，qps为554/s}$，我们再来看下机器的资源使用情况，cpu基本已经被打满。

2.3 性能对比结果

总体性能下降：RT（25%）、QPS（29%）

3. 原因分析

3.1 架构差异

由于应用在容器化后整体架构的不同、访问路径的不同，将可能导致应用容器化后性能的下降，于是我们先来分析下两者架构的区别。我们使用k8s作为容器编排基础设施，网络插件使用calico的ipip模式，整体架构如下所示。

这里需要说明，虽然使用calico的ipip模式，由于pod的访问为service的nodePort模式，所以不会走tunl0网卡，而是从eth0经过iptables后，通过路由到calico的calixxx接口，最后到pod。

3.2性能分析

在上面压测结果的图中，我们容器化后，cpu的软中断si使用率明显高于原先虚拟机的si使用率，所以我们使用perf继续分析下热点函数。

为了进一步验证是否是软中断的影响，我们使用perf进一步统计软中断的次数。

我们发现容器化后比原先软中断多了14%，到这里，我们能基本得出结论，应用容器化以后，需要更多的软中断的网络通信导致了性能的下降。

3.3 软中断原因

由于容器化后，容器和宿主机在不同的网络namespace,数据需要在容器的namespace和host namespace之间相互通信,使得不同namespace的两个虚拟设备相互通信的一对设备为veth pair,可以使用ip link命令创建，对应上面架构图中红色框内的两个设备，也就是calico创建的calixxx和容器内的eth0。我们再来看下veth设备发送数据的过程

static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)

{

...

    if (likely(veth_forward_skb(rcv, skb, rq, rcv_xdp)

...

}



static int veth_forward_skb(struct net_device *dev, struct sk_buff *skb,

			    struct veth_rq *rq, bool xdp)

{

	return __dev_forward_skb(dev, skb) ?: xdp ?

		veth_xdp_rx(rq, skb) :

		netif_rx(skb);//中断处理

}





/* Called with irq disabled */

static inline void ____napi_schedule(struct softnet_data *sd,

				     struct napi_struct *napi)

{

	list_add_tail(&napi->poll_list, &sd->poll_list);

  //发起软中断

	__raise_softirq_irqoff(NET_RX_SOFTIRQ);

}

通过虚拟的veth发送数据和真实的物理接口没有区别，都需要完整的走一遍内核协议栈，从代码分析调用链路为veth_xmit -> veth_forward_skb -> netif_rx -> __raise_softirq_irqoff，veth的数据发送接收最后会使用软中断的方式，这也刚好解释了容器化以后为什么会有更多的软中断，也找到了性能下降的原因。

4. 优化策略

原来我们使用calico的ipip模式，它是一种overlay的网络方案，容器和宿主机之间通过veth pair进行通信存在性能损耗，虽然calico可以通过BGP，在三层通过路由的方式实现underlay的网络通信，但还是不能避免veth pari带来的性能损耗，针对性能敏感的应用，那么有没有其他underly的网络方案来保障网络性能呢？那就是macvlan/ipvlan模式，我们以ipvlan为例稍微展开讲讲。

4.1 ipvlan L2 模式

IPvlan和传统Linux网桥隔离的技术方案有些区别，它直接使用linux以太网的接口或子接口相关联，这样使得整个发送路径变短，并且没有软中断的影响，从而性能更优。如下图所示：

上图是ipvlan L2模式的通信模型，可以看出container直接使用host eth0发送数据，可以有效减小发送路径，提升发送性能。

4.2 ipvlan L3 模式

ipvlan L3模式，宿主机充当路由器的角色，实现容器跨网段的访问，如下图所示：

4.3 Cilium

除了使用macvlan/ipvlan提升网络性能外，我们还可以使用Cilium来提升性能，Cilium为云原生提供了网络、可观测性、网络安全等解决方案，同时它是一个高性能的网络CNI插件，高性能的原因是优化了数据发送的路径，减少了iptables开销，如下图所示：

虽然calico也支持ebpf，但是通过benchmark的对比，Cilium性能更好，高性能名副其实，接下来我们来看看官网公布的一些benchmark的数据，我们只取其中一部分来分析，如下图:

无论从QPS和CPU使用率上Cilium都拥有更强的性能。

5. 总结

容器化带来了敏捷、效率、资源利用率的提升、环境的一致性等等优点的同时，也使得整体的系统复杂度提升一个等级，特别是网络问题，容器化使得整个数据发送路径变长，排查难度增大。不过现在很多网络插件也提供了很多可观测性的能力，帮助我们定位问题。

我们还是需要从实际业务场景出发，针对容器化后性能、安全、问题排查难度增大等问题，通过优化架构，增强基础设施建设才能让我们在云原生的路上越走越远。

最后，感谢大家观看，也希望和我讨论云原生过程中遇到的问题。

5. 参考资料

docs.docker.com/network/dri…

cilium.io/blog/2021/0…

今天周六，Binvin来总结一下上周开发过程中遇到的一个小问题，项目部署后发现服务端无法获取到客户端真实的IP地址，这是怎么回事呢？给我都整懵逼了，经过短暂的思考，我发现了问题的真凶，那就是我们使用了Nginx作的请求转发，这才导致了获取不到客户端真实的IP地址，害，看看我是怎么解决的吧！

问题原因

客户端请求数据时走的是Nginx反向代理，默认情况下客户端的真实IP地址会被其过滤，使得SpringBoot程序无法直接获得真实的客户端IP地址，获取到的都是Nginx的IP地址。

解决方案：

通过更改Nginx配置文件将客户端真实的IP地址加到请求头中，这样就能正常获取到客户端的IP地址了，下面我一步步带你看看如何配置和获取。

修改Nginx配置文件

在需要做请求转发的配置里添加下面的配置

#这个参数设置了HTTP请求头的Host字段，host表示请求的Host头，也就是请求的域名。通过这个设置，Nginx会将请求的Host头信息传递给后端服务。

proxy_set_header Host $host;

#这个参数设置了HTTP请求头的X−Real−IP字段，remote_addr表示客户端的IP地址。通过这个设置，Nginx会将客户端的真实IP地址传递给后端服务

proxy_set_header X-Real-IP $remote_addr;

#这个参数设置了HTTP请求头的 X-Forwarded-For字段，"X-Forwarded-For"是一个标准的HTTP请求头，用于表示HTTP请求经过的代理服务器链路信息，proxy_add_x_forwarded_for表示添加额外的服务器链路信息。

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

修改后我的nginx.conf中的server如下所示

server {

  listen 443 ssl;

  server_name xxx.com;



  ssl_certificate "ssl证书pem文件";

  ssl_certificate_key "ssl证书key文件";

  ssl_session_timeout 5m;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

  ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;

  ssl_prefer_server_ciphers on;



  location / {

    root   前端html文件目录;

    index  index.html index.htm;

  }



  error_page   500 502 503 504  /50x.html;

  location = /50x.html {

    root html;

  }

  # 关键在下面这个配置，上面的配置自己根据情况而定就行

  location /hello{

    proxy_pass http://127.0.0.1:8090;

    proxy_set_header Host $host;

    proxy_set_header X-Real-IP $remote_addr; 

    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  }

}

SpringBoot代码实现

第一种方式：在代码中直接通过X-Forwarded-For获取到真实IP地址

@Slf4j

public class CommonUtil {

    /**

     * <p> 获取当前请求客户端的IP地址 </p>

     *

     * @param request 请求信息

     * @return ip地址

     **/

    public static String getIp(HttpServletRequest request) {

        if (request == null) {

            return null;

        }

        String unknown = "unknown";

        // 使用X-Forwarded-For就能获取到客户端真实IP地址

        String ip = request.getHeader("X-Forwarded-For");

        log.info("X-Forwarded-For:" + ip);

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("Proxy-Client-IP");

            log.info("Proxy-Client-IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("WL-Proxy-Client-IP");

            log.info("WL-Proxy-Client-IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_FORWARDED_FOR");

            log.info("HTTP_X_FORWARDED_FOR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_FORWARDED");

            log.info("HTTP_X_FORWARDED:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_X_CLUSTER_CLIENT_IP");

            log.info("HTTP_X_CLUSTER_CLIENT_IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_CLIENT_IP");

            log.info("HTTP_CLIENT_IP:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_FORWARDED_FOR");

            log.info("HTTP_FORWARDED_FOR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_FORWARDED");

            log.info("HTTP_FORWARDED:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("HTTP_VIA");

            log.info("HTTP_VIA:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getHeader("REMOTE_ADDR");

            log.info("REMOTE_ADDR:" + ip);

        }

        if (ip == null || ip.length() == 0 || unknown.equalsIgnoreCase(ip)) {

            ip = request.getRemoteAddr();

            log.info("getRemoteAddr:" + ip);

        }

        return ip;

    }

第二种方式：在application.yml文件中加以下配置，直接通过request.getRemoteAddr()并可以获取到真实IP

server:

  port: 8090

  tomcat:

    #Nginx转发 获取客户端真实IP配置

    remoteip:

      remote-ip-header: X-Real-IP

      protocol-header: X-Forwarded-Proto

前言

谈不上是多么厉害的知识，但可能确实有人不清楚或没见过。

我还是分享一下，就当一个小知识点。

如果知道的，就随便逛逛，不知道的，Get到了记得顺手点个赞哈。

正文

1、接口别随便暴露

当一个项目的维护周期拉长的时候，不断有新增的需求，如果经手的人也越来越多，接口是会肉眼可见增多的。

此时，如果一个团队没有良好的规范和代码审查机制，就会导致许多不安全的接口被暴露出来。

比如下面这种接口：

/**

* 根据ID查询患者信息

*/

@GetMapping("/{id}")

public AjaxResult getById(@PathVariable("id") Long id) {

    PersonInfo personInfo = personInfoService.selectPersonInfoById(id);

    return AjaxResult.success(personInfo);

}

这种接口是我们部门以前审查出来的其中一个，类似这样的接口还有很多。

这些接口都是不同的同事在紧凑的工作任务中写的，慢慢就积累出了一堆。

还有些是为了方便，直接通过代码生成器生成的，而代码生成器是把常用的CRUD接口都给你生成出来，如果研发人员没有责任心，可能就直接不管了，想着以后哪一天也许会用上呢。

别以为这种想法的人少啊，你整个职业生涯很可能就会遇见。

这就导致了，一堆用不上又不安全的接口出现了。

服务过政务机构、企事业单位、医疗等行业的工程师应该就知道，这些单位对于安全性的要求其实挺高的，尤其是这些年，会找专门的信息安全公司做攻防演练。

最近两年，很多省市甚至会自发组织全市的信息安全攻防演练，在当前大环境下这也是符合国情的。

而攻防演练的目的之一就是找系统安全漏洞，这里面就会有一个我本章要讲的典型漏洞，接口的横向越权。

2、什么是横向越权

广义的解释就是，该越权行为允许用户获取他们正常情况下无权访问的信息或执行操作。

如果纯粹从理论上理解，是很抽象的，所以我才把这个案例捞出来，让你一次就懂。

我们再回过头看看上面我贴出来的那段很正常的代码，就是根据id获取用户信息，你一定曾经在一些项目中见过这种接口，提供给前端直接调用，比如用户详情、订单详情，只要是和详情有关的，很可能前端会需要这么一个接口。

那么，问题在这里，我们的id是不是有规则的呢？比如下面这样：

可以看出来，id是自增的，增量是2。其实很多中小企业现在用MySQL都喜欢这样设置自增id，有些会设置增量，有些干脆就默认。

试想一下，我如果知道了id=865的用户信息，我也知道大部分中小企业喜欢用自增id，是不是就等于知道了1-1000000的用户信息，而用户信息可能包含身-份-证、手机号、详细住址等非常敏感的内容。

这就是典型的横向越权之一，我明明只应该拿到id=865这个用户的信息，但是通过非正常的方式，我暴力获取了其他100万个用户信息。

一旦真的发生这样的事故，不管最终结果如何，这家公司基本上就进黑名单了，从此在行业中消失。

3、权限控制不了吗

一定会有人产生疑惑，SpringBoot接口怎么可能直接放出来，一定都是有权限控制的，没有权限是根本不可能访问到的。

我打个比方，如果是后台管理这种，他是有登录的，登录后会产生token，token中是可以包含角色权限的，那么这种是没有问题的。

但如果没有登录操作呢，比如小程序这种，你打开就直接是首页各种信息，前端调接口很可能传递的只有网关层的token，又该如何呢。

尤其是小程序雨后春笋一般涌现的那几年，我曾经打开过很多小程序，都是没什么权限校验的，就是直接点来点去。

直到近几年，这种现象才慢慢消失，很多小程序打开后，会提示你授权登录，比如微信小程序，你一定遇到过打开小程序后让你授权登录的场景，如果不授权登录，你绝对做不了很多操作，这是很多互联网企业的安全意识都加强的结果。

我所在的公司早年刚进入医疗行业就经历过这种事情，为了占坑拿下了很多项目，但缺乏安全意识和管理规范，程序员也是来来走走，你写两个我写两个，导致不少接口都存在安全隐患。

直到被攻防演练攻破，甲方下发整改通知，还要我们写事故报告、原因、解决方案等等一大堆，我们才慌了。

连夜开会讨论出一套基本的安全整改思路，然后开始加班加点做安全改造。

我印象最深的就是其中这个接口横向越权，只传递了网关层的token，而没有细化到个人的权限控制，导致被信息安全公司通过抓包等一些我不了解的技术把token拿到了，然后直接横向获取到了很多用户敏感信息。

当时这个事情闹得很厉害，考虑到只是攻防演练，同时客户方对公司还保留信任，才只要求我们限期整改，否则就直接替换了。

所以，记得以后写接口的时候别只考虑业务逻辑，安全性也是考量之一。

4、如何防范

防范的方式，我归纳了这么几点：

1、不用的接口尽量删掉，这样也避免了多余接口埋下的安全隐患；

2、团队要有安全规范，比如敏感字段加密，引入代码审查机制，缩小安全隐患出现的范围；

3、带登录的终端，除了网关层校验，要精确控制登录用户的角色及权限；

4、不带登录的终端，除了网关层校验，要根据用户的唯一信息，来做授权登录，授权不成功不允许做其他操作，这也是现在比较流行的方式。

我个人理解，第4点和第3点本质一样，因为不带登录，所以要想办法制造登录，而目前比较友好的方式还是一键授权登录，不管是根据openid、手机号等等，总之要找到一个规则，这样省去了用户手动操作登录的时间。

总之，一定要控制用户只能看到属于自己的内容，避免横向越权。

总结

如果写的不好，还望大家原谅，只是分享了曾经工作中发生过的和安全改造有关的事情。

现在的程序员其实了解和接收的知识技术是挺多的，许多人其实都知道这些。

希望不知道的人，能够因为我的文章得到一点点帮助。

最后，大家其实可以去试一试，打开微信小程序，搜索下你们所在城市的某某中心医院，看看这样的医疗小程序打开后是什么样的，是不是有授权登录，或者其他方式来控制权限，搞不好一部分人能遇到有意思的事情。

快过年，我的线上发布出现故障

“五哥，你在上线吗？”，旁边有一个声音传来。

“啊，怎么了？”。真是要命，在上线发布时候，我最讨厌别人叫我的名字 。我慌忙站起来，看向身后，原来是 建哥在问我。我慌忙的问，怎么回事。

“DBA 刚才在群里说，Task数据库 cpu 负载增加！有大量慢查询”，建哥来我身边，跟我说。

慢慢的，我身边聚集着越来越多的人

“你在上线Task服务吗？改动什么内容了，看看要不要立即回滚？”旁边传来声音。此时，我的心开始怦怦乱跳，手心发痒，紧张不已。

我检查着线上机器的日志，试图证明报警的原因不是出在我这里。

我对着电脑，微微颤抖地回答大家：“我只是升级了基础架构的Jar包，其他内容没有改动啊。”此时我已分不清是谁在跟我说话，只能对着电脑作答……

这时DBA在群里发送了一条SQL，他说这条SQL导致了大量的慢查询。

我突然记起来了，我转过头问林哥：“林哥，你上线了什么内容？”这次林哥有代码的变更，跟我一起上线。我觉得可能是他那边有问题。

果然，林哥看着代码发呆。他嘟囔道：“我添加了索引啊，怎么会有慢查询呢？”原来慢查询的SQL是林哥刚刚添加的，这一刻我心里的石头放下了，问题并不在我，我轻松了许多。

“那我先回滚吧”，幸好我们刚发布了一半，现在回滚还来得及，我尝试回滚机器。此刻我的紧张情绪稍稍平静下来，手也不再发抖。

既然不是我的问题，我可以以吃瓜的心态，暗中观察事态的发展。我心想：真是吓死我了，幸好不是我的错。

然而我也有一些小抱怨：为什么非要和我一起搭车上线，出了事故，还得把我拖进来。

故障发生前的半小时

2年前除夕前的一周，我正准备着过年前的最后一次线上发布，这时候我刚入职两个月，自然而然会被分配一些简单的小活。这次上线的内容是将基础架构的Jar包升级到新版本。一般情况下，这种配套升级工作不会出问题，只需要按部就班上线就行。

“五哥，你是要上线 Task服务吗？”，工位旁的林哥问我，当时我正做着上线前的准备工作。

“对啊，马上要发布，怎么了？”，我转身回复他。

“我这有一个代码变更，跟你搭车一起上线吧，改动内容不太多。已经测试验证过了”，林哥说着，把代码变更内容发给我，简单和我说了下代码变更的内容。我看着改动内容确实不太多，新增了一个SQL查询，于是便答应下来。我重新打包，准备发布上线。

半小时以后，便出现了文章开头的情景。新增加的SQL 导致大量慢查询，数据库险些被打挂。

为什么加了索引，还会出现慢查询呢？

”加了索引，为什么还有慢查询？“，这是大家共同的疑问。

事后分析故障的原因，通过 mysql explain 命令，查看该SQL 确实没有命中索引，从而导致慢查询。

这个SQL 大概长这个样子！我去掉了业务相关的部分。

select * from order_discount_detail where orderId = 1123;

order_discount_detail 在 orderId 这一列上确实加了索引，不应该出现慢查询，乍一看，没有什么问题。我本能的想到了索引失效的几种场景。难道是类型不匹配，导致索引失效？

果不其然， orderId 在数据库中的类型 是 varchar 类型，而传参是按照 long 类型传的。

复习一下： 类型转换导致索引失效

类型转换导致索引失效，是很容易犯的错误

因为在某些特殊场景下要对接外部订单，存在订单Id为字符串的情况，所以 orderId被设计成 varchar 字符串类型。然而出问题的场景比较明确，订单id 就是long类型，不可能是字符串类型。

所以林哥，他在使用Mybatis 时，直接使用 long 类型的 orderId字段传参，并且没有意识到两者数据类型不对。

因为测试环境数据量比较小，即使没有命中索引，也不会有很严重的慢查询，并且测试环境请求量比较低，该慢查询SQL 执行次数较少，所以对数据库压力不大，测试阶段一直没有发现性能问题。

直到代码发布到线上环境————数据量和访问量都非常高的环境，差点把数据库打挂。

mybatis 能避免 “类型转换导致索引失效” 的问题吗？

mybatis能自动识别数据库和Java类型不一致的情况吗？如果发现java类型和数据库类型不一致，自动把java 类型转换为数据库类型，就能避免索引失效的情况！

答案是不能。我没找到 mybatis 有这个能力。

mybatis 使用 #{} 占位符，会自动根据 参数的 Java 类型填充到 SQL中，同时可以避免SQL注入问题。

例如刚才的SQL 在 mybatis中这样写。

select * from order_discount_detail where orderId = #{orderId};

orderId 是 String 类型，SQL就变为

select * from order_discount_detail where orderId = ‘1123’;

mybatis 完全根据 传参的java类型，构建SQL，所以不要认为 mybatis帮你处理好java和数据库的类型差异问题，你需要自己关注这个问题！

再次提醒，"类型转换导致索引失效"的问题，非常容易踩坑。并且很难在测试环境发现性能问题，等到线上再发现问题就晚了，大家一定要小心！小心！

险些背锅

可能有朋友疑问，为什么发布一半时出现慢查询，单机发布阶段不能发现这个问题吗？

之所以没发现这个问题，是因为 新增SQL在 Kafka消费逻辑中，由于单机发布机器启动时没有争抢到 kafka 分片，所以没有走到新代码逻辑。

此外也没有遵循降级上线的代码规范，如果上线默认是降级状态，上线过程中就不会有问题。放量阶段可以通过降级开关快速止损，避免回滚机器过程缓慢而导致的长时间故障。

不是我的问题，为什么我也背了锅

因为我在发布阶段没有遵循规范，按照规定的流程应该在单机发布完成后进行引流压测。引流压测是指修改机器的Rpc权重，将Rpc请求集中到新发布的单机上，这样就能提前发现线上问题。

然而由于我偷懒，跳过了单机引流压测。由于发布的第一台机器没有抢占到Kafka分片，因此无法执行新代码逻辑。即使进行了单机引流压测，也无法提前发现故障。虽然如此，但我确实没有遵循发布规范，错在我。

如果上线时没有出现故障，这种不规范的上线流程可能不会受到责备。但如果出现问题，那只能怪我倒霉。在复盘过程中，我的领导抓住了这件事，给予了重点批评。作为刚入职的新人，被指责确实让我感到不舒服。

快要过年了，就因为搭车上线，自己也要承担别人犯错的后果，让我很难受。但是自己确实也有错，当时我的心情复杂而沉重。

两年前的事了，说出来让大家吃个瓜，乐呵一下。如果这瓜还行，东东发财的小手点个赞

后端接口设计

如果让你设计一个接口，你会考虑哪些问题？

1.接口参数校验

接口的入参和返回值都需要进行校验。

• 入参是否不能为空，入参的长度限制是多少，入参的格式限制，如邮箱格式限制


• 返回值是否为空，如果为空的时候是否返回默认值，这个默认值需要和前端协商

2.接口扩展性

举个例子，比如用户在进行某些操作之后，后端需要进行消息推送，那么是直接针对这个业务流程来开发一个专门为这个业务流程服务的消息推送功能呢？还是说将消息推送整合为一个通用的接口，其他流程都可以进行调用，并非针对特定业务。

这个场景可能光靠说不是很能理解，大家想想策略工厂设计模式，是不是可以根据不同的策略，来选择不同的实现方式呢？再结合上面的这个例子，是否对扩展性有了进一步的理解呢？

3.接口幂等设计

什么是幂等呢？幂等是指多次调用接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致

举个例子，在购物商场里面你用手机下单，要买某个商品，你需要去支付，然后你点击了支付，但是因为网速问题，始终没有跳转到

支付界面，于是你又连点了几次支付，那在没有做接口幂等的时候，是不是你点击了多少次支付，我们就需要执行多少次支付操作？

所以接口幂等到的是什么？防止用户多次调用同一个接口

• 对于查询和删除类型的接口，不论调用多少次，都是不会产生错误的业务逻辑和数据的，因此无需幂等处理


• 对于新增和修改，例如转账等操作，重复提交就会导致多次转账，这是很严重的，影响业务的接口需要做接口幂等的处理，跟前端约定好一个固定的token接口，先通过用户的id获取全局的token，写入到Redis缓存，请求时带上Token，后端做处理

4.关键接口日志打印

关键的业务代码，是需要打印日志进行监测的，在入参和返回值或者如catch代码块中的位置进行日志打印

• 方便排查和定位线上问题，划清责任


• 生产环境是没有办法进行debug的，必须依靠日志查问题，看看到底是出现了什么异常情况

5.核心接口要进行线程池隔离

分类查询啊，首页数据等接口，都有可能使用到线程池，某些普通接口也可能会使用到线程池，如果不做线程池隔离，万一普通接口出现bug把线程池打满了，会导致你的主业务受到影响

6.第三方接口异常重试

如果有场景出现调用第三方接口，或者分布式远程服务的话，需要考虑的问题

• 异常处理
  
  

  比如你在调用别人提供的接口的时候，如果出现异常了，是要进行重试还是直接就是当做失败



• 请求超时
  
  

  有时候如果对方请求迟迟无响应，难道就一直等着吗？肯定不是这样的，需要设法预估对方接口响应时间，设置一个超时断开的机制，以保护接口，提高接口的可用性，举个例子，你去调用别人对外提供的一个接口，然后你去发http请求，始终响应不回来，此时你又没设置超时机制，最后响应方进程假死，请求一直占着线程不释放，拖垮线程池。



• 重试机制
  
  

  如果调用对外的接口失败了或者超时了，是否需要重新尝试调用呢？还是失败了就直接返回失败的数据？

7.接口是否需要采用异步处理

举个例子，比如你实现一个用户注册的接口。用户注册成功时，发个邮件或者短信去通知用户。这个邮件或者发短信，就更适合异步处理。总不能一个通知类的失败，导致注册失败吧。 那我们如何进行异步操作呢？可以使用消息队列，就是用户注册成功后，生产者产生一个注册成功的消息，消费者拉到注册成功的消息，就发送通知。

8.接口查询优化，串行优化为并行

假设我们要开发一个网站的首页，我们设计了一个首页数据查询的接口，这个接口需要查用户信息，需要查头部信息，需要查新闻信息

等等之类的，最简单的就是一个一个接口串行调用，那要是想要提高性能，那就采取并行调用的方式，同时查询，而不是阻塞

可以使用CompletableFuture(推荐)或者FutureTask(不推荐)

        Map<Long, List<SubjectLabelBO>> map = new HashMap<>();

        List<CompletableFuture<Map<Long, List<SubjectLabelBO>>>> completableFutureList = 

        categoryBOList.stream().map(category ->

                CompletableFuture.supplyAsync(() -> getLabelBOList(category), labelThreadPool)

        ).collect(Collectors.toList());

​

        completableFutureList.forEach(future -> {

            try {

                Map<Long, List<SubjectLabelBO>> resultMap = future.get(); //这里会阻塞

                map.putAll(resultMap);

            } catch (Exception e) {

                e.printStackTrace();

            }

        });

        

        public Map<Long, List<SubjectLabelBO>> getLabelBOList(SubjectCategoryBO category) {...}

9.高频接口注意限流

自定义注解 + AOP

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface RateLimiter {

    int value() default 1;

    int durationInSeconds() default 1;

}

​

@Aspect

@Component

public class RateLimiterAspect {

​

    private final ConcurrentHashMap<String, RateLimiter> rateLimiters = new ConcurrentHashMap<>();

​

    @Pointcut("@annotation(RateLimiter)")

    public void rateLimiterPointcut(RateLimiter rateLimiterAnnotation) {

    }

​

    @Around("rateLimiterPointcut(rateLimiterAnnotation)")

    public Object around(ProceedingJoinPoint joinPoint, RateLimiter rateLimiterAnnotation) throws Throwable {

        int permits = rateLimiterAnnotation.value();

        int durationInSeconds = rateLimiterAnnotation.durationInSeconds();

​

        // 使用方法签名作为 RateLimiter 的 key

        String key = joinPoint.getSignature().toLongString();

        com.google.common.util.concurrent.RateLimiter rateLimiter = rateLimiters.computeIfAbsent(key, k -> com.google.common.util.concurrent.RateLimiter.create((double) permits / durationInSeconds));

​

        // 尝试获取令牌，如果获取到则执行方法，否则抛出异常

        if (rateLimiter.tryAcquire()) {

            return joinPoint.proceed();

        } else {

            throw new RuntimeException("Rate limit exceeded.");

        }

    }

}

​

@RestController

public class ApiController {

​

    @GetMapping("/api/limited")

    @RateLimiter(value = 10, durationInSeconds = 60) //限制为每分钟 10 次请求

    public String limitedEndpoint() {

        return "This API has a rate limit of 10 requests per minute.";

    }

​

    @GetMapping("/api/unlimited")

    public String unlimitedEndpoint() {

        return "This API has no rate limit.";

    }

}

10.保障接口安全

配置黑白名单，用Bloom过滤器实现黑白名单的配置

具体代码不贴出来了，大家可以去看看布隆过滤器的具体使用

11.接口控制锁粒度

在高并发场景下，为了防止超卖等情况，我们会对共享资源进行加锁的操作来保证线程安全的问题，但是如果加锁的粒度过大，是会影响

到接口性能的。那什么是加锁粒度呢？举一个例子，你带了一封情书回家，但是不想被爸妈发现，然后你偷偷回到房间里放到一个可以锁

住的抽屉里面，而不用把房间的门锁给锁上。 无论是使用synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉

及共享资源的，就不必要加锁。

• 锁粒度过大：
  
  

  把方法A和方法B全部进行加锁，但是实际上我只是想要对A加锁，这就是锁粒度过大

void test(){

    synchronized (this) {

       B();

       A();

    }

}

• 缩小锁粒度

void test(){

       B();

    synchronized (this) {

       A();

    }

}

12.避免长事务问题

长事务期间可能伴随cpu、内存升高、严重时会导致服务端整体响应缓慢，导致在线应用无法使用

产生长事务的原因除了sql本身可能存在问题外，和应用层的事务控制逻辑也有很大的关系。

• 如何尽可能的避免长事务问题呢？
  
  

  1.RPC远程调用不要放到事务里面

  
  

  2.一些查询相关的操作如果可用，尽量放到事务外面

  
  

  3.并发场景下，尽量避免使用@Transactional注解来操作事务，使用TransactionTemplate的编排式事务来灵活控制事务的范围

在原先使用@Transactional来管理事务的时候是这样的

@Transactional

public int createUser(User user){

    //保存用户信息

    userDao.save(user);

    passCertDao.updateFlag(user.getPassId());

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

使用TransactionTemplat进行编排式事务

@Resource

private TransactionTemplate transactionTemplate;

​

public int createUser(User user){

    transactionTemplate.execute(transactionStatus -> {

      try {

         userDao.save(user);

         passCertDao.updateFlag(user.getPassId());

      } catch (Exception e) {

         // 异常手动设置回滚

         transactionStatus.setRollbackOnly();

      }

      return true;

    });

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

Hello，大家好，我是云帆。在我们传统的基于SpringBoot开发的项目中，在配置文件里，或多或少的都会有一些敏感信息，这样就会丢失一定的安全性，所以我们就需要，对敏感信息进行加密。我们可以使用jasypt工具进行加密。

好了废话不多少，直接进入正题：

1. 导入依赖

<dependency>  

    <groupId>com.github.ulisesbocchio</groupId>  

    <artifactId>jasypt-spring-boot-starter</artifactId>  

    <version>3.0.5</version>  

</dependency>

我的Demo里使用的是SpringBoot3.0之后的版本，所以大家如果像我一样都是基于SpringBoot3.0之后的，jasypt一定要使用3.0.5以后的版本。

2. 使用jasypt

我们在配置文件里写几行配置

jasypt:  

  encryptor:  

    password: sdjsdbshdbfuasd  

    property:  

      prefix: ENC(

      suffix: )

password是加密密码，必须配置这一项，值可以随便输入。
prefix和suffix是默认配置，也可以自定义，默认值就是ENC(和)，这个是自动解密使用的。

2.1. 加/解密

jasypt 提供了一个工具类接口，StringEncryptor，这个接口提供了加解密方法。下面是他的源码。

public interface StringEncryptor {  

  

    /**  

    * 加密输入信息  

    *  

    * @param 要加密的信息  

    * @return 加密结果  

    */  

    public String encrypt(String message);  





    /**  

    * 解密加密信息  

    *  

    * @param 加密信息（encryptedMessage） 要解密的加密信息  

    * @return 解密结果  

    */  

    public String decrypt(String encryptedMessage);  

  

}

我们在 test 测试类中，将要进行加密的文本使用encrypt方法进行加密

@SpringBootTest  

@Slf4j  

class JasryptApplicationTests {  

  

    @Autowired  

    private StringEncryptor stringEncryptor;  



    @Test  

    void contextLoads() {  

        String username = stringEncryptor.encrypt("root");  

        String password = stringEncryptor.encrypt("root");  

        log.info("username encrypt is {}", username);  

        log.info("password encrypt is {}", password);  

        log.info("username decrypt is {}", stringEncryptor.decrypt(username));  

        log.info("password decrypt is {}", stringEncryptor.decrypt(password));  

    }  

  

}

上边代码，加密的内容是，MySQL的用户名和密码，同时对它们进行加密和解密，你当然可以对任意配置信息进行加解密操作。看看输出内容：

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username encrypt is 61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password encrypt is a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv

2023-07-23T18:59:50.623+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username decrypt is root

2023-07-23T18:59:50.630+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password decrypt is root

加密默认使用的是PBEWITHHMACSHA512ANDAES_256加密
我们将密文，替换到数据源，配置：

spring:  

datasource:  

driver-class-name: com.mysql.cj.jdbc.Driver  

url: jdbc:mysql://localhost:3306/honey?useUnicode=true&zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=utf-8  

username: ENC(61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot)  

password: ENC(a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv)

⚠️注意别忘了加上前缀和后缀，如上边代码。

这个时候就已经完成了，但是官方不建议我们将加密密码放到配置文件中，我们应作为系统属性、命令行参数或环境变量传递，只要其名称是 jasypt.encryptor.password，就能正常工作。

我们可以将项目打为jar包然后使用 java -jar命令

java -jar jasrypt-0.0.1-SNAPSHOT.jar --jasypt.encryptor.password=加密密码

⚠️加密密码必须与之前给属性加密时用的加密密码一致。

3. 结尾

好了，分享到这里就结束了，希望小伙伴们多多点赞，如果有建议，欢迎留言。

此致

引言：纯干货分享，汇总了我在工作中八年遇到的各种 Nginx 使用场景，对这篇文章进行了细致的整理和层次分明的讲解，旨在提供简洁而深入的内容。希望这能为你提供帮助和启发！

对于前端开发人员来说，Node.js 是一种熟悉的技术。虽然 Nginx 和 Node.js 在某些理念上有相似之处，比如都支持 HTTP 服务、事件驱动和异步非阻塞操作，但两者并不冲突，各有各自擅长的领域：

• Nginx：擅长处理底层的服务器端资源，如静态资源处理、反向代理和负载均衡。


• Node.js：更擅长处理上层的具体业务逻辑。

而两者的结合可以实现更加高效和强大的应用服务架构，下面我们就来看一下。借助文章目录阅读，效率更高。目前您可能还用不到这篇文章，不过可以先收藏起来。希望将来它能为您提供所需的帮助！

Nginx 是什么？

Nginx 是一个高性能的HTTP和反向代理服务器，由俄罗斯程序员Igor Sysoev于 2004 年使用 C 语言开发。它最初设计是为了应对俄罗斯大型门户网站的高流量挑战。

反向代理是什么？（🔥面试会问）

让我们先从代理说起。Nginx 常被用作反向代理，那么什么是正向代理呢？

• 正向代理：客户端知道要访问的服务器地址，但服务器只知道请求来自某个代理，而不清楚具体的客户端。正向代理隐藏了真实客户端的信息。例如，当无法直接访问国外网站时，我们通过代理服务器访问特定网址。

• 反向代理：多个客户端向反向代理服务器发送请求，Nginx 根据一定的规则将请求转发至不同的服务器。客户端不知道具体请求将被转发至哪台服务器，反向代理隐藏了后端服务器的信息。

Nginx 的核心特性

Nginx包含以下七个核心特性，使它成为处理高并发和大数据量请求的理想选择：

1. 事件驱动：Nginx采用高效的异步事件模型，利用 I/O 多路复用技术。这种模型使 Nginx 能在占用最小内存的同时处理大量并发连接。

2. 高度可扩展：Nginx能够支持数千乃至数万个并发连接，非常适合大型网站和高并发应用。例如：为不同的虚拟主机设置不同的 worker 进程数，以增加并发处理能力：

http {

  worker_processes auto; # 根据系统CPU核心数自动设置worker进程数

}

3. 轻量级：相较于传统的基于进程的Web服务器（如Apache），Nginx的内存占用更低，得益于其事件驱动模型，每个连接只占用极小的内存空间。

4. 热部署：Nginx支持热部署功能，允许在不重启服务器的情况下更新配置和模块。例如：在修改了 Nginx 配置文件后，可以快速热部署 Nginx 配置：

sudo nginx -s reload

5. 负载均衡：Nginx内置负载均衡功能，通过upstream模块实现客户端请求在多个后端服务器间的分配，从而提高服务的整体处理能力。以下是一个简单的upstream配置，它将请求轮询分配到三个后端服务器：

upstream backend {

    server backend1.example.com;

    server backend2.example.com;

    server backend3.example.com;

}



server {

    location / {

        proxy_pass http://backend; # 将请求转发到upstream定义的backend组

    }

}

6. 高性能：Nginx 在多项 Web 性能测试中表现卓越，能快速处理静态文件、索引文件及代理请求。比如：配置 Nginx 作为反向代理服务器，为大型静态文件下载服务：

location /files/ {

  alias /path/to/files/; # 设置实际文件存储路径

  expires 30d; # 设置文件过期时间为30天

}

7. 安全性：Nginx支持SSL/TLS协议，能够作为安全的Web服务器或反向代理使用。

server {

  listen 443 ssl;

  ssl_certificate /path/to/fullchain.pem; # 证书路径

  ssl_certificate_key /path/to/privatekey.pem; # 私钥路径

  ssl_protocols TLSv1.2 TLSv1.3; # 支持的SSL协议

}

搭建 Nginx 服务

如何安装？

在 Linux 系统中，可以使用包管理器来安装 Nginx。例如，在基于 Debian 的系统上，可以使用 apt：

sudo apt update

sudo apt install nginx

在基于 Red Hat 的系统上，可以使用 yum 或 dnf：

sudo yum install epel-release

sudo yum install nginx

在安装完成后，通常可以通过以下命令启动 Nginx 服务：

sudo systemctl start nginx

设置开机自启动：

sudo systemctl enable nginx

启动成功后，在浏览器输入服务器 ip 地址或者域名，如果看到 Nginx 的默认欢迎页面，说明 Nginx 运行成功。

常用命令有哪些

在日常的服务器管理和运维中，使用脚本来管理 Nginx 是很常见的。这可以帮助自动化一些常规任务，如启动、停止、重载配置等。以下是一些常用的 Nginx 脚本命令，这些脚本通常用于 Bash 环境下：

其他常用的配合脚本命令：

。。。还有哪些常用命令，评论区一起讨论下！

配置文件构成（🔥核心重点，一定要了解）

Nginx配置文件主要由指令组成，这些指令可以分布在多个上下文中，主要上下文包括：

worker_processes auto;   # worker_processes定义Nginx可以启动的worker进程数，auto表示自动检测 



# 定义Nginx如何处理连接 

events {   

    worker_connections 1024;  # worker_connections定义每个worker进程可以同时打开的最大连接数 

}  

  

# 定义HTTP服务器的参数  

http {  

    include mime.types;  # 引入mime.types文件，该文件定义了不同文件类型的MIME类型  

    default_type application/octet-stream;  # 设置默认的文件MIME类型为application/octet-stream  

    sendfile on;  # 开启高效的文件传输模式  

    keepalive_timeout 65;  # 设置长连接超时时间  



    # 定义一个虚拟主机  

    server {  

        listen 80;  # 指定监听的端口

        server_name localhost;  # 设置服务器的主机名，这里设置为localhost  

        

        # 对URL路径进行配置  

        location / {  

            root /usr/share/nginx/html;  # 指定根目录的路径  

            index index.html index.htm;  # 设置默认索引文件的名称，如果请求的是一个目录，则按此顺序查找文件  

        }  



        # 错误页面配置，当请求的文件不存在时，返回404错误页面  

        error_page 404 /404.html;  



        # 定义/40x.html的位置  

        location = /40x.html {  

            # 此处可以配置额外的指令，如代理、重写等，但在此配置中为空  

        }  



        # 错误页面配置，当发生500、502、503、504等服务器内部错误时，返回相应的错误页面  

        error_page 500 502 503 504 /50x.html;  



        # 定义/50x.html的位置  

        location = /50x.html {  

            # 同上，此处可以配置额外的指令  

        }  

    }  

}

这个配置文件设置了Nginx监听80端口，使用root指令指定网站的根目录，并为404和50x错误页面提供了位置。其中，user和worker_processes指令在main上下文中，events块定义了事件处理配置，http块定义了HTTP服务器配置，包含一个server块，该块定义了一个虚拟主机，以及两个location块，分别定义了对于404和50x错误的处理。

进入正题，详细看下如何配置

打开 Nginx 配置世界大门

下面这段是 Nginx 配置定义了一个服务器块（server block），它指定了如何处理发往特定域名的 HTTP 请求。

server {

    listen 80;  # 监听80端口，HTTP请求的默认端口

    client_max_body_size 100m;  # 设置客户端请求体的最大大小为100MB

    index index.html;  # 设置默认的索引文件为index.html

    root /user/project/admin;  # 设置Web内容的根目录为/user/project/admin



    # 路由配置，处理所有URL路径

    location ~ /* {

        proxy_pass http://127.0.0.1:3001;  # 将请求代理到本机的3001端口

        proxy_redirect off;  # 关闭代理重定向



        # 设置代理请求头，以便后端服务器可以获取客户端的原始信息

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;



        # 定义代理服务器失败时的行为，如遇到错误、超时等，尝试下一个后端服务器

        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

        proxy_max_temp_file_size 0;  # 禁止代理临时文件写入



        # 设置代理连接、发送和读取的超时时间

        proxy_connect_timeout 90;

        proxy_send_timeout 90;

        proxy_read_timeout 90;



        # 设置代理的缓冲区大小

        proxy_buffer_size 4k;

        proxy_buffers 4 32k;

        proxy_busy_buffers_size 64k;

        proxy_temp_file_write_size 64k;

    }



    # 对图片文件设置缓存过期时间，客户端可以在1天内使用本地缓存

    location ~ .*.(gif|jpg|jpeg|png|swf)$ {

        expires 1d; 

    }



    # 对JavaScript和CSS文件设置缓存过期时间，客户端可以在24小时内使用本地缓存

    location ~ .*.(js|css)?$ {

        expires 24h;

    }



    # 允许访问/.well-known目录下的所有文件，通常用于WebFinger、OAuth等协议

    location ~ /.well-known {

        allow all;

    }



    # 禁止访问隐藏文件，即以点开头的文件或目录

    location ~ /. {

        deny all;

    }



    # 指定访问日志的路径，日志将记录在/user/logs/admin.log文件中

    access_log /user/logs/admin.log;

}

注意：Nginx 支持使用正则表达式来匹配 URI，这极大地增强了配置的灵活性。在 Nginx 配置中，正则表达式通过 ~ 来指定。

例如，location ~ /* 可以匹配所有请求。另一个例子是 location ~ .*.(gif|jpg|jpeg|png|swf)$，这个表达式用于匹配以 gif、jpg、jpeg、png 或 swf 这些图片文件扩展名结尾的请求。

Nginx 配置实战（🔥可以复制，直接拿来使用）

以下是一些常见的 Nginx 配置实战案例：

1、静态资源服务：前端web

server {

    listen 80;

    server_name example.com;

    location / {

        root /path/to/your/static/files;

        index index.html index.htm;

    }

    location ~* \.(jpg|png|gif|jpeg)$ {

        expires 30d;

        add_header Cache-Control "public";

    }

}

在这个案例中，Nginx 配置为服务静态文件，如 HTML、CSS、JavaScript 和图片等。通过设置 root 指令，指定了静态文件的根目录。同时，对于图片文件，通过 expires 指令设置了缓存时间为 30 天，减少了服务器的负载和用户等待时间。

2、反向代理

server {

    listen 80;

    server_name api.example.com;

    location / {

        proxy_pass http://backend;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

}

这个案例展示了如何配置 Nginx 作为反向代理服务器。当客户端请求 api.example.com 时，Nginx 会将请求转发到后端服务器集群。通过设置 proxy_set_header，可以修改客户端请求的头部信息，确保后端服务器能够正确处理请求。

3、负载均衡

http {

    upstream backend {

        server backend1.example.com;

        server backend2.example.com;

        server backend3.example.com;

    }

    server {

        listen 80;

        server_name example.com;

        location / {

            proxy_pass http://backend;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        }

    }

}

在这个负载均衡的案例中，Nginx 将请求分发给多个后端服务器。通过 upstream 指令定义了一个服务器组，然后在 location 块中使用 proxy_pass 指令将请求代理到这个服务器组。Nginx 支持多种负载均衡策略，如轮询（默认）、IP 哈希等。

4、HTTPS 配置

server {

    listen 443 ssl;

    server_name example.com;

    ssl_certificate /path/to/your/fullchain.pem;

    ssl_certificate_key /path/to/your/private.key;

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';

    ssl_prefer_server_ciphers on;

    location / {

        root /path/to/your/https/static/files;

        index index.html index.htm;

    }

}

这个案例展示了如何配置 Nginx 以支持 HTTPS。通过指定 SSL 证书和私钥的路径，以及设置 SSL 协议和加密套件，可以确保数据传输的安全。同时，建议使用 HTTP/2 协议以提升性能。

5、安全防护

server {

    listen 80;

    server_name example.com;

    location / {

        # 防止 SQL 注入等攻击

        rewrite ^/(.*)$ /index.php?param=$1 break;

        # 限制请求方法，只允许 GET 和 POST

        if ($request_method !~ ^(GET|POST)$ ) {

            return 444;

        }

        # 防止跨站请求伪造

        add_header X-Frame-Options "SAMEORIGIN";

        add_header X-Content-Type-Options "nosniff";

        add_header X-XSS-Protection "1; mode=block";

    }

}

通过 rewrite 指令，可以防止一些常见的 Web 攻击，如 SQL 注入。这种限制请求方法，可以减少服务器被恶意利用的风险。同时，添加了一些 HTTP 头部来增强浏览器安全，如防止点击劫持和跨站脚本攻击（XSS）等。

Nginx 深入学习-负载均衡

在负载均衡的应用场景中，Nginx 通常作为反向代理服务器，接收客户端的请求并将其分发到一组后端服务器。这样做不仅可以分散负载、提升网站的响应速度，更能提高系统的可用性。

健康检查

Nginx 能够监测后端服务器的健康状态。如果服务器无法正常工作，Nginx 将自动将请求重新分配给其他健康的服务器。

http {

    upstream myapp1 { # 定义了后端服务器组

        server srv1.example.com;

        server srv2.example.com;

        server srv3.example.com;

        

        # 健康检查配置。

        # 每10秒进行一次健康检查，如果连续3次健康检查失败，则认为服务器不健康；

        # 如果连续2次健康检查成功，则认为服务器恢复健康。

        check interval=10s fails=3 passes=2;

    }



    server {

        listen 80;



        location / {

            proxy_pass http://myapp1;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        }

    }

}

check interval=10s fails=3 passes=2; 这样的配置语法在开源版本的 NGINX 上是不支持的。这是 ngx_http_upstream_check_module 模块的特有语法，而该模块不包含在 NGINX 的开源版本中，需要自行下载、编译和安装。该模块是开源免费的，具体详情请参见 ngx_http_upstream_check_module 文档。

Nginx 会定期向定义的服务器发送健康检查请求。如果服务器响应正常，则认为服务器健康；如果服务器没有响应或者响应异常，则认为服务器不健康。当服务器被标记为不健康时，Nginx 将不再将请求转发到该服务器，直到它恢复健康。

负载均衡算法

Nginx 支持多种负载均衡算法，可以适应不同的应用场景。以下是几种常见的负载均衡算法的详细说明和示例：

1、Weight轮询（默认）：权重轮询算法是 Nginx 默认的负载均衡算法。它按顺序将请求逐一分配到不同的服务器上。通过设置服务器权重（weight）来调整不同服务器上请求的分配率。

upstream backend {

  server backend1.example.com weight=3; # 设置backend1的权重为3

  server backend2.example.com; # backend2的权重为默认值1

  server backend3.example.com weight=5; # 设置backend3的权重为5

}

如果某一服务器宕机，Nginx会自动将该服务器从队列中剔除，请求代理会继续分配到其他健康的服务器上。

2、IP Hash 算法： 根据客户端IP地址的哈希值分配请求，确保客户端始终连接到同一台服务器。

upstream backend {

  ip_hash; # 启用IP哈希算法

  server backend1.example.com;

  server backend2.example.com;

}

根据客户端请求的IP地址的哈希值进行匹配，将具有相同IP哈希值的客户端分配到指定的服务器。这样可以确保同一客户端的请求始终被分配到同一台服务器，有助于保持用户的会话状态。

3、fair算法： 根据服务器的响应时间和负载来分配请求。

upstream backend {

  fair; # 启用公平调度算法

  server backend1.example.com;

  server backend2.example.com;

  server backend3.example.com;

}

它结合了轮询和IP哈希的优点，但Nginx默认不支持公平调度算法，需要安装额外的模块（upstream_fair）来实现。

4、URL Hash 算法： 根据请求的 URL 的哈希值分配请求，每个请求的URL会被分配到指定的服务器，有助于提高缓存效率。

upstream backend {

  hash $request_uri; # 启用URL哈希算法

  server backend1.example.com;

  server backend2.example.com;

}

# 根据请求的URL哈希值来决定将请求发送到backend1还是backend2。

这种方法需要安装Nginx的hash软件包。

开源模块

Nginx拥有丰富的开源模块，有很多还有待我们探索，除了一些定制化的需求需要自己开发，大部分的功能都有开源。大家可以在 NGINX 社区、GitHub 上搜索 "nginx module" 可以找到。

总结

虽然前端人员可能不经常直接操作 Nginx，但了解其基本概念和简单的配置操作是必要的。这样，在需要自行配置 Nginx 的情况下，前端人员能够知晓如何进行基本的设置和调整。

引言

最近公司整改，招了个安全测试，安全测试的同事搞了个危险的文件，悄咪咪加了个.png的后缀，就丢到我们的生产服务器上面去了，这么勇，你敢信？

不管你信不信，事实他就是发生了，就问你怕不怕。

好了，这里也就暴露了一个很大的问题，我们的开发同事判断文件类型，是使用文件后缀来判断的，所以被直接跳过。咱来看看更加科学的识别方式。

一、认识魔数

魔数：也被称为签名或文件签名，是一种用于识别文件类型和格式的短序列字节。它们通常位于文件的开头，并被设计为易于识别，以便软件可以快速确定文件是否是它所支持的格式。

魔数是一种简单的识别机制，它由一系列字节组成，这些字节在特定的文件格式中是唯一的。当一个程序打开一个文件时，它会检查文件的开始处是否包含这些特定的字节。如果找到，程序就认为文件是该格式的，并按照相应的规则进行解析和处理。

二、文件类型检测的原理

文件类型检测通常基于文件的“魔数”（magic number），也称为签名或文件签名。魔数是文件开头的字节序列，用于标识文件格式。以下是文件类型检测的原理和步骤：

2.1 文件头的读取方法

打开文件：首先，需要以二进制模式打开文件，以便能够读取文件的原始字节。

读取字节：接着，读取文件开头的一定数量的字节（通常是前几个字节）。

关闭文件：读取完成后，关闭文件以释放资源。

2.2 如何通过文件头识别文件类型

比较魔数：将读取的字节与已知的文件类型魔数进行比较。

匹配类型：如果字节序列与某个文件类型的魔数匹配，则可以确定文件类型。

处理异常：如果字节序列与任何已知魔数都不匹配，可能需要进一步的分析或返回未知文件类型。

三、Java实现文件类型检测

当需要通过文件头（魔数头）判断文件类型时，可以按照以下文字描述的流程进行实现：

graph LR

F[打开文件] --> B[读取文件头]

B --> C[判断文件类型]

C --> D[比较文件头]

D --> E[输出文件类型]



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

3.1 具体实现方法

3.1.1 定义枚举类

/**

 * 文件类型魔数枚举

 * 使用场景：用于判断文件类型

 * 使用方法：FileUtils.isFileType(new FileInputStream(file), FileTypeEnum.XLSX)

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:37

 */

public enum FileTypeEnum {

    /**

     * JPEG

     */

    JPEG("JPEG", "FFD8FF"),



    /**

     * PNG

     */

    PNG("PNG", "89504E47"),



    /**

     * GIF

     */

    GIF("GIF", "47494638"),



    /**

     * TIFF

     */

    TIFF("TIFF", "49492A00"),



    /**

     * Windows bitmap

     */

    BMP("BMP", "424D"),



    /**

     * CAD

     */

    DWG("DWG", "41433130"),



    /**

     * Adobe photoshop

     */

    PSD("PSD", "38425053"),



    /**

     * Rich Text Format

     */

    RTF("RTF", "7B5C727466"),



    /**

     * XML

     */

    XML("XML", "3C3F786D6C"),



    /**

     * HTML

     */

    HTML("HTML", "68746D6C3E"),



    /**

     * Outlook Express

     */

    DBX("DBX", "CFAD12FEC5FD746F "),



    /**

     * Outlook

     */

    PST("PST", "2142444E"),



    /**

     * doc;xls;dot;ppt;xla;ppa;pps;pot;msi;sdw;db

     */

    OLE2("OLE2", "0xD0CF11E0A1B11AE1"),



    /**

     * Microsoft Word/Excel

     */

    XLS_DOC("XLS_DOC", "D0CF11E0"),



    /**

     * Microsoft Access

     */

    MDB("MDB", "5374616E64617264204A"),



    /**

     * Word Perfect

     */

    WPB("WPB", "FF575043"),



    /**

     * Postscript

     */

    EPS_PS("EPS_PS", "252150532D41646F6265"),



    /**

     * Adobe Acrobat

     */

    PDF("PDF", "255044462D312E"),



    /**

     * Windows Password

     */

    PWL("PWL", "E3828596"),



    /**

     * ZIP Archive

     */

    ZIP("ZIP", "504B0304"),



    /**

     * ARAR Archive

     */

    RAR("RAR", "52617221"),



    /**

     * WAVE

     */

    WAV("WAV", "57415645"),



    /**

     * AVI

     */

    AVI("AVI", "41564920"),



    /**

     * Real Audio

     */

    RAM("RAM", "2E7261FD"),



    /**

     * Real Media

     */

    RM("RM", "2E524D46"),



    /**

     * Quicktime

     */

    MOV("MOV", "6D6F6F76"),



    /**

     * Windows Media

     */

    ASF("ASF", "3026B2758E66CF11"),



    /**

     * MIDI

     */

    MID("MID", "4D546864"),

    /**

     * xlsx

     */

    XLSX("XLSX", "504B0304"),

    /**

     * xls

     */

    XLS("XLS", "D0CF11E0A1B11AE1");



    private String key;

    private String value;



    FileTypeEnum(String key, String value) {

        this.key = key;

        this.value = value;

    }



    public String getValue() {

        return value;

    }



    public String getKey() {

        return key;

    }

}

3.1.2 文件类型判断工具类

import java.io.IOException;

import java.io.InputStream;



/**

 * 文件类型判断工具类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:38

 */

public class FileTypeUtils {



    /**

     * 获取文件头

     *

     * @param inputStream 输入流

     * @return 16 进制的文件投信息

     * @throws IOException io异常

     */

    private static String getFileHeader(InputStream inputStream) throws IOException {

        byte[] b = new byte[28];

        inputStream.read(b, 0, 28);

        inputStream.close();

        return bytes2hex(b);

    }



    /**

     * 将字节数组转换成16进制字符串

     *

     * @param src 文件字节数组

     * @return 16进制字符串

     */

    private static String bytes2hex(byte[] src) {

        StringBuilder stringBuilder = new StringBuilder("");

        if (src == null || src.length <= 0) {

            return null;

        }

        for (byte b : src) {

            int v = b & 0xFF;

            String hv = Integer.toHexString(v);

            if (hv.length() < 2) {

                stringBuilder.append(0);

            }

            stringBuilder.append(hv);

        }

        return stringBuilder.toString();

    }



    /**

     * 判断指定输入流是否是指定文件格式

     *

     * @param inputStream  输入流

     * @param fileTypeEnum 文件格式枚举

     * @return true 是； false 否

     * @throws IOException io异常

     */

    public static boolean isFileType(InputStream inputStream, FileTypeEnum fileTypeEnum) throws IOException {

        if (null == inputStream) {

            return false;

        }

        String fileHeader = getFileHeader(inputStream);

        return fileHeader.toUpperCase().startsWith(fileTypeEnum.getValue());

    }



}

3.1.3 测试方法

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.IOException;



/**

 * 测试：判断文件是否是excel

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:33

 */

public class Test {



    public static void main(String[] args) {

        File file = new File("C:\Users\Admin\Desktop\temp\Import file.xlsx");

        try (FileInputStream fileInputStream = new FileInputStream(file)) {

            if (!FileTypeUtils.isFileType(fileInputStream, FileTypeEnum.XLSX) || !FileTypeUtils.isFileType(fileInputStream, FileTypeEnum.XLS)) {

                System.out.println(true);

            } else {

                System.out.println(false);

            }

        } catch (FileNotFoundException e) {

            e.printStackTrace();

        } catch (IOException e) {

            e.printStackTrace();

        }

    }



}

四、其它注意事项

在处理文件类型检测和数据保护时，安全性和隐私是两个非常重要的考虑因素。以下是一些相关的安全性问题和最佳实践：

4.1 魔数检测的安全性问题

graph LR

F(文件类型判断)

B(魔数检测的安全性问题)

C(误报和漏报)

D(恶意文件伪装)

E(更新和维护)



F ---> B

B ---> C

B ---> D

B ---> E



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

4.2 数据保护和隐私的最佳实践

graph LR

I(文件类型判断)



A(数据保护和隐私的最佳实践)



G(最小权限原则)

B(数据加密)

C(安全的数据传输)

D(访问控制)

E(定期审计和测试)

F(数据最小化)



I ---> A

A ---> B

A ---> C

A ---> D

A ---> E

A ---> F

A ---> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

style G fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style A fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#EEDD82,stroke:#EEDD82,stroke-width:2px

4.3 魔数的局限性和风险

魔数判断文件类型是一种常用的方法，但也存在一些局限性和风险，包括以下几点：

graph LR

I(文件类型判断)



A(魔数的局限性和风险)



B(可伪造性)

C(文件类型扩展性)

D(文件损坏或篡改)

E(多重文件类型)

F(文件类型模糊性)



I ---> A

A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

style A fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#EEDD82,stroke:#EEDD82,stroke-width:2px

五、总结

好了，到这里魔数怎么用的就说明白了。

魔数的广泛的应用在在文件类型检测中。魔数是文件开头的特定字节序列，帮助软件快速识别文件格式。

然而，魔数检测存在安全性问题，如误报、恶意伪装等，需定期更新魔数库。此外，应用魔数检测时要考虑文件损坏、多重类型等局限性，结合实际情况采取综合措施，如数据加密、访问控制等，确保安全性和准确性。

希望本文对您有所帮助。如果有任何错误或建议，请随时指正和提出。

同时，如果您觉得这篇文章有价值，请考虑点赞和收藏。这将激励我进一步改进和创作更多有用的内容。

感谢您的支持和理解！

大家好呀，我是summo，JDK版本升级的非常快，现在已经到JDK20了。JDK版本虽多，但应用最广泛的还得是JDK8，正所谓“他发任他发，我用Java8”。

其实我也不太想升级JDK版本，感觉投入高，收益小，不过有一次我看到了一些使用JDK17新语法写的代码，让我改变了对升级JDK的看法，因为这些新语法我确实想用！

废话不多说，上代码！

一、JDK17语法新特性

1. 文本块

这个更新非常实用。在没有这个特性之前，编写长文本非常痛苦。虽然IDEA等集成开发工具可以自动处理，但最终效果仍然丑陋，充满拼接符号。现在，通过字符串块，我们可以轻松编写JSON、HTML、SQL等内容，效果更清爽。这个新特性值得五颗星评价，因为它让我们只需关注字符串本身，而无需关心拼接操作。

原来的写法

/**

 * 使用JDK8返回HTML文本

 *

 * @return 返回HTML文本

 */

public static final String getHtmlJDK8() {

    return "<html>\n" +

        " <body>\n" +

        " <p>Hello, world</p>\n" +

        " </body>\n" +

        "</html>";

}

新的写法

/**

 * 使用JDK17返回HTML文本

 *

 * @return 返回HTML文本

 */

public static final String getHtmlJDK17() {

    return """

        <html>

            <body>

                <p>Hello, world</p>

            </body>

        </html>

        """;

}

推荐指数：⭐️⭐️⭐️⭐️⭐️

2. NullPointerException增强

这一功能非常强大且实用，相信每位Java开发者都期待已久。空指针异常（NPE）一直是Java程序员的痛点，因为报错信息无法直观地指出哪个对象为空，只抛出一个NullPointerException和一堆堆栈信息，定位问题耗时且麻烦。尤其在遇到喜欢级联调用的代码时，逐行排查更是令人头疼。如果在测试环境中，可能还需通过远程调试查明空对象，费时费力。为此，阿里的编码规范甚至不允许级联调用，但这并不能彻底解决问题。Java17终于在这方面取得了突破，提供了更详细的空指针异常信息，帮助开发者迅速定位问题源头。

public static void main(String[] args) {

    try {

        //简单的空指针

        String str = null;

        str.length();

    } catch (Exception e) {

        e.printStackTrace();

    }

    try {

        //复杂一点的空指针

        var arr = List.of(null);

        String str = (String)arr.get(0);

        str.length();

    } catch (Exception e) {

        e.printStackTrace();

    }

}

运行结果

推荐指数：⭐️⭐️⭐️⭐️⭐️

3. Records

在Java中，POJO对象（如DO、PO、VO、DTO等）通常包含成员变量及相应的Getter和Setter方法。尽管可以通过工具或IDE生成这些代码，但修改和维护仍然麻烦。Lombok插件为此出现，能够在编译期间自动生成Getter、Setter、hashcode、equals和构造函数等代码，使用起来方便，但对团队有依赖要求。
为此，Java引入了标准解决方案：Records。它通过简洁的语法定义数据类，大大简化了POJO类的编写，如下所示。虽然hashcode和equals方法仍需手动编写，但IDE能够自动生成。这一特性有效解决了模板代码问题，提升了代码整洁度和可维护性。

package com.summo.jdk17;



/**

 * 3星

 *

 * @param stuId     学生ID

 * @param stuName   学生名称

 * @param stuAge    学生年龄

 * @param stuGender 学生性别

 * @param stuEmail  学生邮箱

 */

public record StudentRecord(Long stuId,

                            String stuName,

                            int stuAge,

                            String stuGender,

                            String stuEmail) {

    public StudentRecord {

        System.out.println("构造函数");

    }



    public static void main(String[] args) {

        StudentRecord record = new StudentRecord(1L, "张三", 16, "男", "xxx@qq.com");

        System.out.println(record);

    }

}

推荐指数：⭐️⭐️⭐️⭐️

4. 全新的switch表达式

有人可能问了，Java语言不早已支持switch了嘛，有什么好提的？讲真，这次的提升还真有必要好好地来聊一聊了。在Java12的时候就引入了switch表达式，注意这里是表达式，而不是语句，原来的switch是语句。如果不清楚两者的区别的话，最好先去了解一下。主要的差别就是就是表达式有返回值，而语句则没有。再配合模式匹配，以及yield和“->”符号的加入，全新的switch用起来爽到飞起来。

package com.summo.jdk17;



public class SwitchDemo {

    /**

     * 在JDK8中获取switch返回值方式

     *

     * @param week

     * @return

     */

    public int getByJDK8(Week week) {

        int i = 0;

        switch (week) {

            case MONDAY, TUESDAY:

                i = 1;

                break;

            case WEDNESDAY:

                i = 3;

                break;

            case THURSDAY:

                i = 4;

                break;

            case FRIDAY:

                i = 5;

                break;

            case SATURDAY:

                i = 6;

                break;

            case SUNDAY:

                i = 7;

                break;

            default:

                i = 0;

                break;

        }



        return i;

    }



    /**

     * 在JDK17中获取switch返回值

     *

     * @param week

     * @return

     */

    public int getByJDK17(Week week) {

        // 1, 现在的switch变成了表达式，可以返回值了，而且支持yield和->符号来返回值

        // 2, 再也不用担心漏写了break，而导致出问题了

        // 3, case后面支持写多个条件

        return switch (week) {

            case null -> -1;

            case MONDAY -> 1;

            case TUESDAY -> 2;

            case WEDNESDAY -> 3;

            case THURSDAY -> {yield 4;}

            case FRIDAY -> 5;

            case SATURDAY, SUNDAY -> 6;

            default -> 0;

        };

    }



    private enum Week {

        MONDAY,

        TUESDAY,

        WEDNESDAY,

        THURSDAY,

        FRIDAY,

        SATURDAY,

        SUNDAY

    }

}

推荐指数：⭐️⭐️⭐️⭐️

5. 私有接口方法

从Java8开始，允许在interface里面添加默认方法，其实当时就有些小困惑，如果一个default方法体很大怎么办，拆到另外的类去写吗？实在有些不太合理，所以在Java17里面，如果一个default方法体很大，那么可以通过新增接口私有方法来进行一个合理的拆分了，为这个小改进点个赞。

public interface PrivateInterfaceMethod {

    /**

     * 接口默认方法

     */

    default void defaultMethod() {

        privateMethod();

    }



    // 接口私有方法，在Java8里面是不被允许的，不信你试试

    private void privateMethod() {

    }

}

推荐指数：⭐️⭐️⭐️

6. 模式匹配

在JDK 17中，模式匹配主要用于instanceof表达式。模式匹配增强了instanceof的语法和功能，使类型检查和类型转换更加简洁和高效。在传统的Java版本中，我们通常使用instanceof结合类型转换来判断对象类型并进行处理，这往往会导致冗长的代码。

原来的写法

/**

 * 旧式写法

 *

 * @param value

 */

public void matchByJDK8(Object value) {

    if (value instanceof String) {

        String v = (String)value;

        System.out.println("遇到一个String类型" + v.toUpperCase());

    } else if (value instanceof Integer) {

        Integer v = (Integer)value;

    System.out.println("遇到一个整型类型" + v.longValue());

    }

}

新的写法

/**

 * 转换并申请了一个新的变量，极大地方便了代码的编写

 *

 * @param value

 */

public void matchByJDK17(Object value) {

    if (value instanceof String v) {

        System.out.println("遇到一个String类型" + v.toUpperCase());

    } else if (value instanceof Integer v) {

        System.out.println("遇到一个整型类型" + v.longValue());

    }

}

推荐指数：⭐️⭐️⭐️⭐️

7. 集合类的工厂方法

在Java8的年代，即便创建一个很小的集合，或者固定元素的集合都是比较麻烦的，为了简洁一些，有时我甚至会引入一些依赖。

原来的写法

Set<String> set = new HashSet<>();

set.add("a");

set.add("b");

set.add("c"

新的写法

Set<String> set = Set.of("a", "b", "c");

推荐指数：⭐️⭐️⭐️⭐️⭐️

二、其他的新特性

1. 新的String方法

• repeat：重复生成字符串


• isBlank：不用在引入第三方库就可以实现字符串判空了


• strip：去除字符串两边的空格，支持全角和半角，之前的trim只支持半角


• lines：能根据一段字符串中的终止符提取出行为单位的流


• indent：给字符串做缩进，接受一个int型的输入


• transform：接受一个转换函数，实现字符串的转换

2. Stream API的增强

增加takeWhile, dropWhile, ofNullable, iterate以及toList的API，越来越像一些函数式语言了。用法举例如下。

// takeWhile 顺序返回符合条件的值，直到条件不符合时即终止继续判断，

// 此外toList方法的加入，也大大减少了节省了代码量，免去了调用collect(Collectors::toList)方法了

List<Integer> list = Stream.of(2,2,3,4,5,6,7,8,9,10)

        .takeWhile(i->(i%2==0)).toList(); // 返回2, 2



// dropWhile 顺序去掉符合条件的值，直到条件不符合时即终止继续判断

List<Integer> list1 = Stream.of(2,2,3,4,5,6,7,8,9,10)

        .dropWhile(i->(i%2==0)).toList(); //返回3, 4, 5, 6, 7, 8, 9, 10



// ofNullable，支持传入空流，若没有这个且传入一个空流，那么将会抛NPE

var nullStreamCount = Stream.ofNullable(null).count(); //返回0



// 以下两行都将输出0到9

Stream.iterate(0, n -> n < 10, n -> n + 1).forEach(x -> System.out.println(x));

Stream.iterate(0, n -> n + 1).limit(10).forEach(x -> System.out.println(x));

3. 全新的HttpClient

这个API首次出现在9之中，不过当时并非是一个稳定版本，在Java11中正式得到发布，所以在Java17里面可以放心地进行使用。原来的JDK自带的Http客户端真的非常难用，这也就给了很多像okhttp、restTemplate、Apache的HttpClient和feign这样的第三方库极大的发挥空间，几乎就没有人愿意去用原生的Http客户端的。但现在不一样了，感觉像是新时代的API了。FluentAPI风格，处处充满了现代风格，用起来也非常地方便，再也不用去依赖第三方的包了，就两个字，清爽。

// 同步请求

HttpClient client = HttpClient.newBuilder()

        .version(Version.HTTP_1_1)

        .followRedirects(Redirect.NORMAL)

        .connectTimeout(Duration.ofSeconds(20))

        .proxy(ProxySelector.of(new InetSocketAddress("proxy.example.com", 80)))

        .authenticator(Authenticator.getDefault())

        .build();

   HttpResponse<String> response = client.send(request, BodyHandlers.ofString());

   System.out.println(response.statusCode());

   System.out.println(response.body()); 

// 异步请求

HttpRequest request = HttpRequest.newBuilder()

        .uri(URI.create("https://foo.com/"))

        .timeout(Duration.ofMinutes(2))

        .header("Content-Type", "application/json")

        .POST(BodyPublishers.ofFile(Paths.get("file.json")))

        .build();

   client.sendAsync(request, BodyHandlers.ofString())

        .thenApply(HttpResponse::body)

        .thenAccept(System.out::println);

 

4. jshell

在新的JDK版本中，支持直接在命令行下执行java程序，类似于python的交互式REPL。简而言之，使用 JShell，你可以输入代码片段并马上看到运行结果，然后就可以根据需要作出调整，这样在验证一些简单的代码的时候，就可以通过jshell得到快速地验证，非常方便。

5. java命令直接执行java文件

在现在可以直接通过执行“java xxx.java”，即可运行该java文件，无须先执行javac，然后再执行java，是不是又简单了一步。

6. ZGC

在ParallelOldGC、CMS和G1之后，JDK 11引入了全新的ZGC（Z Garbage Collector）。这个名字本身就显得很牛。官方宣称ZGC的垃圾回收停顿时间不超过10ms，能支持高达16TB的堆空间，并且停顿时间不会随着堆的增大而增加。那么，ZGC到底解决了什么问题？Oracle官方介绍它是一个可伸缩的低延迟垃圾回收器，旨在降低停顿时间，尽管这可能会导致吞吐量的降低。不过，通过横向扩展服务器可以解决吞吐量问题。官方已建议ZGC可用于生产环境，这无疑将成为未来的主流垃圾回收器。要了解更多，请参阅官方文档。

三、小结一下

作为程序员，持续学习和充电非常重要。随着Java8即将停止免费官方支持，越来越多的项目将转向Java17，包括大名鼎鼎的Spring Boot 3.0，它在2022年1月20日发布的第一个里程碑版本（M1）正是基于Java17构建的。该项目依赖的所有组件也将快速升级，未来如果想利用某些新特性，在Java8下将无法通过编译.，到这时候再换就真的晚了... ...

个人项目：社交支付项目（小老板）

作者：三哥，j3code.cn

文档系统：admire.j3code.cn/note

社交支付类的项目，怎么能没有图片上传功能呢！

涉及到文件存储我第一时间就想到了 OSS 对象存储服务（腾讯叫 COS），但是接着我又想到了”OSS 被刷 150 T 的流量，1.5 W 瞬间就没了？“。

本来想着是自己搭建一套 MinIO ，但后来一想服务器的开销又要大了，还是作罢了。就在此时，我脑袋突然灵光了一下，既然对象存储的流量是由于资源 url 泄漏导致的外界不停的访问 url 使公网流量剧增从而引起巨额消费，那我能不能不泄露这个 url 呢！

理论上是可以不直接给用户云存储的 url ，那用户如何访问资源？

转换，当用户上传图片时，将云存储的 url 保存入库，而返回用户一个本系统的资源访问接口。当用户访问该接口时，系统从库中获取真实 url 进行资源访问，并返回资源给用户，完成一次转换。

虽然可以解决 url 泄漏问题，但是也是有性能消耗（从直接访问，变为间接访问，而且系统挂了，资源就不可用）。

方案，虽然曲折了点，但为了 money ，牺牲一点是值得的（后来思考了一下，觉得还是有些问题，文章最后会说）。而且即使有人通过刷系统的接口访问资源，也没事，系统有很强的限流和黑名单处理，不会产生过多的公网流量费用的。

那下面我们就先开通相关功能，然后再编码实现。

1、腾讯云对象存储创建

地址：console.cloud.tencent.com/cos

开通对象存储的步骤还是非常简单的，具体步骤如下：

1）开通功能

2）配置存储桶

下一步

下一步

3）创建访问的密钥

腾讯的所有 API 接口都需要这个访问密钥，如果以前创建过就可以直接拿来使用

下一步

基本的功能我们已经开通了，而且以后我们只需向这个存储桶中上传图片即可。

2、SpringBoot 对接对象存储

既然准备工作都已经完成了，那就开始编写上传文件的代码吧！当然，这里我们还是要借助官方文档，便于我们开发，地址如下：

cloud.tencent.com/document/pr…

2.1 配置准备

先来思考一下，对于腾讯 COS 文件上传需要那些配置：

ok，大致就这些，那咱们就先来写个配置文件：application-cos.yml

tx.cos:

  # 云 API 的 SecretId

  secret-id: ENC(X7Uu6Y0QD6aCeUmNhyqv1jcr8fSN+fqM/FSP/rqhM+6pkbte2LW5gR3wntsm24n3NAg6sIwBC3pqm1lSNWwElc3iuGe3lE4L/k3zih+EstM=)

  # 云 API 的 SecretKey

  secret-key: ENC(ui3jqYJpyTRtPAizYdtll2Zc1EVzUjK28vjTyD+t3AIydQO6I+JQOVacc5+NJVybsbFptELswKhY55OQLW+BKfujNTOYEM/zb4CMi+AK80w=)

  # 域名访问

  domain: ENC(oRsaRjwRCVLEYfcNB0CjPGyqSMxGM5uzWnSpSifauLF7c5YMt5hZFi7xAthJI4CjmOLVA810Jbgy8lnkKrXUH0g1ee14cr67xSdtPRy1ZaJOXQOMlBgCKNO2wDBg2YW2)

  # 文件上传的桶名称

  bucket-name: ENC(TUsQfDEFx6KSAOpRwG7UYOJbGwnFT0Z9tjS4h+/HeenAE3XbhKsCwn3TTo80n5tUUP9Dzrnu+Ck84FNSYQk5fw==)



spring:

  servlet:

    multipart:

      # 限制文件上传大小

      max-request-size: 5MB

      max-file-size: 5MB

注：这里，我的配置值是加密的，所以你们需要配置自己的值

再根据这个配置文件，写一个对应的配置类：

地址：cn.j3code.common.config

@Slf4j

@Data

@Configuration

@ConfigurationProperties(prefix = "tx.cos")

public class TxCosConfig {

    /**

     * 访问域名

     */

    private String domain;



    /**

     * 桶名称

     */

    private String bucketName;



    /**

     * api密钥中的secretId

     */

    private String secretId;



    /**

     * api密钥中的应用密钥

     */

    private String secretKey;

}

2.2 上传文件代码

这里，我们先实现单个文件的上传，那来思考一下，上传文件应该需要那些步骤：

对应此步骤的流程图，如下：

1）controller 编写

位置：cn.j3code.other.api.v1.controller

@Slf4j

@AllArgsConstructor

@ResponseResult

@RestController

@RequestMapping(UrlPrefixConstants.WEB_V1 + "/image/upload")

public class ImageUploadController {



    private final FileService fileService;





    /**

     * 图片上传

     * @param file 文件

     * @return 返回文件 url

     */

    @PostMapping("")

    public String upload(@RequestParam("file") MultipartFile file){

        return fileService.imageUpload(file);

    }

}

2）service 编写

位置：cn.j3code.other.service

public interface FileService {

    String imageUpload(MultipartFile file);

}



@Slf4j

@AllArgsConstructor

@Service

public class FileServiceImpl implements FileService {



    /**

     * 允许上传的图片类型

     */

    public static final Set<String> IMG_TYPE = Set.of("jpg", "jpeg", "png", "gif");



    /**

     * 腾讯 cos 配置

     */

    private final TxCosConfig txCosConfig;

    private final UrlKeyService urlKeyService;



    /**

     * 图片上传

     *

     * @param file

     * @return

     */

    @Override

    public String imageUpload(MultipartFile file) {

        // 文件名称

        String newFileName = getNewFileName(file);



        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");

        String format = formatter.format(LocalDate.now());

        // key = /用户id/年月日/文件

        String key = SecurityUtil.getUserId() + "/" + format + "/" + newFileName;



        String prefix = newFileName.substring(0, newFileName.lastIndexOf(".") - 1);

        String suffix = newFileName.substring(newFileName.lastIndexOf(".") + 1);

        File tempFile = null;

        File rename = null;

        try {

            // 生成临时文件

            tempFile = File.createTempFile(prefix, "." + suffix);

            file.transferTo(tempFile);

            // 重命名文件

            rename = FileUtil.rename(tempFile, newFileName, true, true);

            // 上传

            upload(new FileInputStream(rename), key);

        } catch (Exception e) {

            log.error("imageUpload-error:", e);

        } finally {

            if (Objects.nonNull(tempFile)) {

                FileUtil.del(tempFile);

            }

            if (Objects.nonNull(rename)) {

                FileUtil.del(rename);

            }

        }

        // 返回访问链接

        return initUrl(key);

    }



    /**

     * 初始化图片文件访问 url（本地url和第三方url）

     *

     * @param key 路径

     * @return

     */

    private String initUrl(String key) {

        // 组装第三方 url

        String imageUrl = txCosConfig.getDomain() + "/" + key;



        // 保存 url 到 数据库

        UrlKey urlKey = new UrlKey()

            .setUrl(imageUrl)

            .setKey(RandomUtil.randomString(16) + RandomUtil.randomString(16) + RandomUtil.randomString(16))

            .setUserId(SecurityUtil.getUserId());



        // 保存成功，返回本地中转的 url 出去

        boolean save = Boolean.FALSE;

        try {

            save = urlKeyService.save(urlKey);

        } catch (Exception e) {

        }



        if (save) {

            return CallbackUrlConstants.IMAGE_OPEN_URL + urlKey.getKey();

        }

        // 保存失败，直接把第三方 url 返回给用户

        return imageUrl;

    }



    /**

     * 文件上传到第三方

     *

     * @param fileStream 文件流

     * @param path       路径

     */

    private void upload(InputStream fileStream, String path) {

        PutObjectResult putObjectResult = COSClientUtil.getCosClient(txCosConfig)

            .putObject(new PutObjectRequest(txCosConfig.getBucketName(), path, fileStream, null));

        log.info("upload-result:{}", JSON.toJSONString(putObjectResult));

    }



    /**

     * 生成一个新文件名称

     * 会校验文件名称和类型

     *

     * @param file 文件

     * @return

     */

    private String getNewFileName(MultipartFile file) {

        String originalFilename = file.getOriginalFilename();

        if (StringUtil.isEmpty(originalFilename)) {

            throw new SysException("文件名称获取失败！");

        }

        String suffix = originalFilename.substring(originalFilename.lastIndexOf("."));



        if (!IMG_TYPE.contains(suffix.substring(1))) {

            throw new SysException(String.format("仅允许上传这些类型图片：%s", JSON.toJSONString(IMG_TYPE)));

        }



        return RandomUtil.randomString(8) + SnowFlakeUtil.getId() + suffix;

    }

}

代码写的很详细了，应该能看懂，但，有两点我没有提，就是：COSClientUtil 和 UrlKeyService，下面就来结介绍。

2.2.1 cos 客户端配置提取

系统中肯定有很多的文件上传，难道是每上传一次，就配置一次 cos 客户端吗？显然不是，这个 cos 客户端肯定是要抽出来的，全局系统中我们只配置一次。也即只有第一次过来是创建 cos 客户端，后续过来的文件上传请求直接返回创建好的 cos 客户端就行。

COSClientUtil 类就是我抽的公共 cos 客户获取类，具体实现如下：

位置：cn.j3code.other.util

public class COSClientUtil {



    /**

     * 统一 cos 上传客户端

     */

    private static COSClient cosClient;



    public static COSClient getCosClient(TxCosConfig txCosConfig) {

        if (Objects.isNull(cosClient)) {

            synchronized (COSClient.class) {

                if (Objects.isNull(cosClient)) {

                    // 1 初始化身份

                    COSCredentials cred = new BasicCOSCredentials(txCosConfig.getSecretId(), txCosConfig.getSecretKey());

                    // 2 创建配置，及设置地域

                    ClientConfig clientConfig = new ClientConfig(new Region("ap-guangzhou"));

                    // 3 生成 cos 客户端。

                    cosClient = new COSClient(cred, clientConfig);

                }

            }

        }

        return cosClient;

    }

}

私有构造器，且之对外提供 getCosClient 方法获取 COSClient 对象，保证全局只有一个 cos 客户端配置。

2.2.2 隐藏云存储 URL 处理

还记得 FileServiceImpl 类中有个 UrlKeyService 属性嘛，这个类就是做 云存储 URL 隐藏及中转功能的。

具体做法如图：

文件上传部分我们已经写好了，不过有点超前的意思了，不过没关系，看整体就行。

从上面我们要开始抓住一个细节了，就是映射关系，即 key 和 url 的映射。这里我用的是 MySQL 保存，也即用表来存，并没有用 Redis。这里我的考虑是，后续可以把表中的数据定时刷到 Redis 中，接着访问的顺序是从 Redis 中找映射，没有再去 MySQL 中找。

不过，我们首先还是把数据先存表再说，先来看看映射表结构字段：

id

user_id

key

url

create_time

update_time

ok，就这些字段，把用户 id 加上是为了好回溯看看是谁上传了图片。

SQL 如下：

CREATE TABLE `sb_url_key` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `key` varchar(64) COLLATE utf8_unicode_ci NOT NULL COMMENT 'key',

  `url` varchar(200) COLLATE utf8_unicode_ci NOT NULL COMMENT '资源url',

  `user_id` bigint(20) DEFAULT NULL COMMENT '上传用户',

  `create_time` datetime DEFAULT NULL COMMENT '创建时间',

  `update_time` datetime DEFAULT NULL COMMENT '修改时间',

  PRIMARY KEY (`id`),

  KEY `key` (`key`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

紧接着就是通过 MyBatisX 插件生成对应的实体、service、mapper 代码了，不过多赘述。那，现在就来开发用户访问图片资源，咱们如何去请求第三方，然后返回用户图片 byte[] 资源数组吧！

1）controller 编写

位置：cn.j3code.other.api.v1.controller

@Slf4j

@AllArgsConstructor

@RestController

@RequestMapping(UrlPrefixConstants.OPEN + "/resource/image")

public class ImageResourceController {



    private final UrlKeyService urlKeyService;



    /**

     * 获取图片 base64

     *

     * @param key

     * @return

     * @throws Exception

     */

    @GetMapping("/base64/{key}")

    public String imageBase64(@PathVariable("key") String key) throws Exception {

        UrlKey urlKey = urlKeyService.oneByKey(key);

        return "data:image/jpg;base64," + Base64Encoder.encode(IoUtil.readBytes(new URL(urlKey.getUrl()).openStream()));

    }





    /**

     * 获取图片 byte 数组

     *

     * @param key

     * @return

     * @throws Exception

     */

    @GetMapping(value = "/io/{key}", produces = MediaType.IMAGE_JPEG_VALUE)

    public byte[] imageIo(@PathVariable("key") String key) throws Exception {

        UrlKey urlKey = urlKeyService.oneByKey(key);



        return IoUtil.readBytes(new URL(urlKey.getUrl()).openStream());

    }

}

注意：这里写了两个方法，目的是返回两种不同形式的图片资源：base64 和 byte[]。且，这种资源访问的接口，我们系统的相关拦截器请放行，如：认证，ip 记录等拦截器。

2）service 编写

位置：cn.j3code.other.service

public interface UrlKeyService extends IService<UrlKey> {

    UrlKey oneByKey(String key);

}

@Service

public class UrlKeyServiceImpl extends ServiceImpl<UrlKeyMapper, UrlKey>

    implements UrlKeyService {



    @Override

    public UrlKey oneByKey(String key) {

        UrlKey urlKey = lambdaQuery().eq(UrlKey::getKey, key).one();

        if (Objects.isNull(urlKey)) {

            throw new SysException(SysExceptionEnum.NOT_DATA_ERROR);

        }

        return urlKey;

    }

}

ok，这样咱们就处理好了，但是仔细想想这种中转的方法有什么问题。

2.3 思考

2.2 节我们已经实现了文件上传和防止 cos 访问 url 泄露的操作，但是我留了个问题，就是思考这种方式有什么问题。

下面是我的思考：

好吧，其实上面总结就两个问题，即：性能 和 可用性。

这里的解决方法是，如果资金充裕而且 COS 做了黑白名单等之类的防御措施可以直接把 COS 的原始 url 返回出去，没必要把图片资源压力给我我们本系统。如果你不是这种情况，那么就给图片访问接口增加部署资源，即升级服务器增加内存和带款，提高资源访问效率及系统性能。

以上就是本节内容，如果文章的中转方法有啥不足或者您有什么意见，欢迎一起讨论研究。

为了节省dalaos时间先说结论：确实是个问题，issue链接：github.com/mybatis/myb…

下面就是源码分析环节，及处理过程，感兴趣的可以看看。

bug，任何时候都要解决！不解决不行，你们想想，你早上刚到公司，打开电脑，写着需求听着歌，突然就被ding了……所以没有bug的日子才是好日子！

日志

上了服务器一看，Mybatis报错，接口还是个相当频繁的接口，一想，完了，绩效大概率不保。

2023-08-08 09:52:05,386|aaaaaaaaa|XXXXXXXXXXXXXX|unknown exception occurred

org.mybatis.spring.MyBatisSystemException: nested exception is org.apache.ibatis.builder.BuilderException: Error evaluating expression 'projects != null and projects.size() > 0 '. Cause: org.apache.ibatis.ognl.MethodFailedException: Method "size" failed for object [aaa,bbb,ccc] [java.lang.IllegalAccessException: Class org.apache.ibatis.ognl.OgnlRuntime can not access a member of class java.util.Arrays$ArrayList with modifiers "public"]

        at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:75) ~[mybatis-spring-1.2.2.jar:1.2.2]

        at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:371) ~[mybatis-spring-1.2.2.jar:1.2.2]

        at com.sun.proxy.$Proxy57.selectList(Unknown Source) ~[na:na]

        at org.mybatis.spring.SqlSessionTemplate.selectList(SqlSessionTemplate.java:198) ~[mybatis-spring-1.2.2.jar:1.2.2]

        at org.apache.ibatis.binding.MapperMethod.executeForMany(MapperMethod.java:119) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:63) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:52) ~[mybatis-3.2.8.jar:3.2.8]

        at com.sun.proxy.$Proxy102.queryExperienceCardOrder(Unknown Source) ~[na:na]

      // 业务相关堆栈，保险起见不贴了

        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204) ~[spring-core-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:652) ~[spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at com.xxxxxxxxxxxxxxxxxxxxxx$$EnhancerBySpringCGLIB$$b85a94bd.queryHasExperienceCardNew(<generated>) ~[zuhao-user-service-1.0.0.jar:na]

        at sun.reflect.GeneratedMethodAccessor564.invoke(Unknown Source) ~[na:na]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_131]

        at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_131]

        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333) ~[spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) [spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) [spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at xxxxxxxxxxxxx.common.interceptor.ApiInterceptor.invoke(ApiInterceptor.java:79) ~[common-0.0.9-20211228.052440-12.jar:na]

        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) [spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) [spring-aop-4.3.6.RELEASE.jar:4.3.6.RELEASE]

        at com.sun.proxy.$Proxy185.queryHasExperienceCardNew(Unknown Source) [na:na]

        at com.alibaba.dubbo.common.bytecode.Wrapper36.invokeMethod(Wrapper36.java) [na:2.5.3]

        at com.alibaba.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:46) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:72) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:53) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:64) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke$original$LFhJaVNd(MonitorFilter.java:65) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke$original$LFhJaVNd$accessor$urPnHrIw(MonitorFilter.java) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.monitor.support.MonitorFilter$auxiliary$RJHyKBeq.call(Unknown Source) [dubbo-2.5.3.jar:2.5.3]

        at org.apache.skywalking.apm.agent.core.plugin.interceptor.enhance.InstMethodsInter.intercept(InstMethodsInter.java:86) [skywalking-agent.jar:8.16.0]

        at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.TimeoutFilter.invoke(TimeoutFilter.java:42) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.dubbo.filter.TraceFilter.invoke(TraceFilter.java:78) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.ContextFilter.invoke(ContextFilter.java:60) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.GenericFilter.invoke(GenericFilter.java:112) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.ClassLoaderFilter.invoke(ClassLoaderFilter.java:38) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.filter.EchoFilter.invoke(EchoFilter.java:38) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol$1.reply(DubboProtocol.java:108) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequest(HeaderExchangeHandler.java:84) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:170) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:52) [dubbo-2.5.3.jar:2.5.3]

        at com.alibaba.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:82) [dubbo-2.5.3.jar:2.5.3]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_131]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_131]

        at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]

Caused by: org.apache.ibatis.builder.BuilderException: Error evaluating expression 'projects != null and projects.size() > 0 '. Cause: org.apache.ibatis.ognl.MethodFailedException: Method "size" failed for object [u号租, 租号牛, 租号酷] [java.lang.IllegalAccessException: Class org.apache.ibatis.ognl.OgnlRuntime can not access a member of class java.util.Arrays$ArrayList with modifiers "public"]

        at org.apache.ibatis.scripting.xmltags.OgnlCache.getValue(OgnlCache.java:47) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.ExpressionEvaluator.evaluateBoolean(ExpressionEvaluator.java:32) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.IfSqlNode.apply(IfSqlNode.java:33) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.MixedSqlNode.apply(MixedSqlNode.java:32) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.TrimSqlNode.apply(TrimSqlNode.java:54) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.MixedSqlNode.apply(MixedSqlNode.java:32) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.TrimSqlNode.apply(TrimSqlNode.java:54) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.MixedSqlNode.apply(MixedSqlNode.java:32) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.DynamicSqlSource.getBoundSql(DynamicSqlSource.java:40) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.mapping.MappedStatement.getBoundSql(MappedStatement.java:278) ~[mybatis-3.2.8.jar:3.2.8]

        at com.github.pagehelper.PageInterceptor.intercept(PageInterceptor.java:83) ~[pagehelper-5.1.4.jar:na]

        at org.apache.ibatis.plugin.Plugin.invoke(Plugin.java:60) ~[mybatis-3.2.8.jar:3.2.8]

        at com.sun.proxy.$Proxy234.query(Unknown Source) ~[na:na]

        at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:108) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.session.defaults.DefaultSqlSession.selectList(DefaultSqlSession.java:102) ~[mybatis-3.2.8.jar:3.2.8]

        at sun.reflect.GeneratedMethodAccessor347.invoke(Unknown Source) ~[na:na]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_131]

        at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_131]

        at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:358) ~[mybatis-spring-1.2.2.jar:1.2.2]

        ... 54 common frames omitted

Caused by: org.apache.ibatis.ognl.MethodFailedException: Method "size" failed for object [aaa,bbb,ccc]

        at org.apache.ibatis.ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:837) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.OgnlRuntime.callMethod(OgnlRuntime.java:860) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.ASTMethod.getValueBody(ASTMethod.java:73) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.ASTChain.getValueBody(ASTChain.java:109) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.ASTGreater.getValueBody(ASTGreater.java:49) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.ASTAnd.getValueBody(ASTAnd.java:56) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.SimpleNode.getValue(SimpleNode.java:210) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:333) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.ognl.Ognl.getValue(Ognl.java:310) ~[mybatis-3.2.8.jar:3.2.8]

        at org.apache.ibatis.scripting.xmltags.OgnlCache.getValue(OgnlCache.java:45) ~[mybatis-3.2.8.jar:3.2.8]

        ... 72 common frames omitted

赶紧查了下这个接口的调用情况，大部分没问题，偶尔冒了这么个错（还好还好）

根据堆栈反查错误位置，有点想不通，这里会有问题？那就只能翻源码了

源码分析

经过排查，ognl表达式中用到的方法，会通过反射，获取method，并缓存至静态变量中，所以，存在多线程状态中，产生并发问题，往下看

这里是缓存方法的逻辑，org.apache.ibatis.ognl.OgnlRuntime#getMethods(java.lang.Class, boolean)感兴趣的可以自己看

这里就是bug点，如果调用一旦多，存在A线程修改成true，还没调用方法，B线程就修改成false，此时调用失败，这不是个坑吗

mybatis中一搜果然有这个issue：github.com/mybatis/myb…

作者给的方案呢是升级mybatis。

你以为就这样结束了？

升级是不可能升级的，这辈子都不可能升级的，代码这么稳定，行行都像诗句[狗头]

开个玩笑，看看如何避免

原因呢就是Arrays.asList返回的是内部类，是private。所以导致了(!Modifier.isPublic(method.getModifiers()) || !Modifier.isPublic(method.getDeclaringClass().getModifiers()))这个条件为true，进入了设置
accessible的逻辑，后面又给设置回原样

总结

• 问题：如果需要ognl的对象的方法和类不是public，那么会存在并发问题


• 解决1：针对并发问题，升级Mybatis


• 解决2：Lists.newArrayList或者其他写法代替，反正看下，内部类是不是private

有问题希望留言指出哈

引言

HashMap相信所有学Java的都一定不会感到陌生，作为一个非常重用且非常实用的Java提供的容器，它在我们的代码里面随处可见。因此遍历操作也是我们经常会使用到的。HashMap的遍历方式现如今有非常多种：

以上遍历方式的孰优孰劣，在《阿里巴巴开发手册》中写道：

这里推荐使用的是entrySet进行遍历，在Java8中推荐使用Map.forEach()。给出的理由是遍历次数上的不同。

其中keySet遍历了两次，一次是转为Iterator对象，另一次是从hashMap中取出key所对应的value。

其中后面一段话很好理解，但是前面这句话却有点绕，为什么转换成了Iterator遍历了一次？

我查阅了各个平台对HashMap的遍历，其中都没有或者原封不动的照搬上句话。（当然也可能是我没有查阅到靠谱的文章，欢迎指正）

keySet如何遍历了两次

我们首先写一段代码，使用keySet遍历Map。

public class Test {





    public static void main(String[] args) {

        Map<String, String> map = new HashMap<>();

        map.put("k1", "v1");

        map.put("k2", "v2");

        map.put("k3", "v3");

        for (String key : map.keySet()) {

            String value = map.get(key);

            System.out.println(key + ":" + value);

        }

    }



}

运行结果显而易见的是

k1:v1

k2:v2

k3:v3

两次遍历，第一次遍历所描述的是转为Iterator对象我们好像没有从代码中看见，我们看到的后面所描述的遍历，也就是遍历map,keySet()所返回的Set集合中的key，然后去HashMap中拿取value的。

Iterator对象呢？如何遍历转换为Iterator对象的呢？

首先我们这种遍历方式大家都应该知道是叫：增强for循环，for-each

这是一种Java的语法糖~。可以看上篇文章了解~

我们可以通过反编译，或者直接通过Idea在class文件中查看对应的Class文件

public class Test {

    public Test() {

    }



    public static void main(String[] args) {

        Map<String, String> map = new HashMap();

        map.put("k1", "v1");

        map.put("k2", "v2");

        map.put("k3", "v3");

        Iterator var2 = map.keySet().iterator();



        while(var2.hasNext()) {

            String key = (String)var2.next();

            String value = (String)map.get(key);

            System.out.println(key + ":" + value);

        }



    }

}

和我们编写的是存在差异的，其中我们可以看到其中通过map.keySet().iterator()获取到了我们所需要看见的Iterator对象。

那么它又是怎么转换成的呢？为什么需要遍历呢？我们查看iterator()方法

iterator()

发现是Set定义的一个接口。返回此集合中元素的迭代器

HashMap.KeySet#iterator()

我们查看HashMap中keySet类对该方法的实现。

    final class KeySet extends AbstractSet<K> {

        public final int size()                 { return size; }

        public final void clear()               { HashMap.this.clear(); }

        public final Iterator<K> iterator()     { return new KeyIterator(); }

        public final boolean contains(Object o) { return containsKey(o); }

        public final boolean remove(Object key) {

            return removeNode(hash(key), key, null, false, true) != null;

        }

        public final Spliterator<K> spliterator() {

            return new KeySpliterator<>(HashMap.this, 0, -1, 0, 0);

        }

        public final void forEach(Consumer<? super K> action) {

            Node<K,V>[] tab;

            if (action == null)

                throw new NullPointerException();

            if (size > 0 && (tab = table) != null) {

                int mc = modCount;

                for (int i = 0; i < tab.length; ++i) {

                    for (Node<K,V> e = tab[i]; e != null; e = e.next)

                        action.accept(e.key);

                }

                if (modCount != mc)

                    throw new ConcurrentModificationException();

            }

        }

    }

其中的iterator()方法返回的是一个KeyIterator对象，那么究竟是在哪里进行了遍历呢？我们接着往下看去。

HashMap.KeyIterator

    final class KeyIterator extends HashIterator

        implements Iterator<K> {

        public final K next() { return nextNode().key; }

    }

这个类也很简单：

还是没有看见哪里进行了遍历，那么我们继续查看HashIterator类

HashMap.HashIterator

    abstract class HashIterator {

        Node<K,V> next;        // next entry to return

        Node<K,V> current;     // current entry

        int expectedModCount;  // for fast-fail

        int index;             // current slot



        HashIterator() {

            expectedModCount = modCount;

            Node<K,V>[] t = table;

            current = next = null;

            index = 0;

            if (t != null && size > 0) { // advance to first entry

                do {} while (index < t.length && (next = t[index++]) == null);

            }

        }



        public final boolean hasNext() {

            return next != null;

        }



        final Node<K,V> nextNode() {

            Node<K,V>[] t;

            Node<K,V> e = next;

            if (modCount != expectedModCount)

                throw new ConcurrentModificationException();

            if (e == null)

                throw new NoSuchElementException();

            if ((next = (current = e).next) == null && (t = table) != null) {

                do {} while (index < t.length && (next = t[index++]) == null);

            }

            return e;

        }



        public final void remove() {

            Node<K,V> p = current;

            if (p == null)

                throw new IllegalStateException();

            if (modCount != expectedModCount)

                throw new ConcurrentModificationException();

            current = null;

            K key = p.key;

            removeNode(hash(key), key, null, false, false);

            expectedModCount = modCount;

        }

    }

我们可以发现这个构造器中存在了一个do-while循环操作，目的是找到一个第一个不为空的entry。

        HashIterator() {

            expectedModCount = modCount;

            Node<K,V>[] t = table;

            current = next = null;

            index = 0;

            if (t != null && size > 0) { // advance to first entry

                do {} while (index < t.length && (next = t[index++]) == null);

            }

        }

而KeyIterator是extendHashIterator对象的。这里涉及到了继承的相关概念，大家忘记的可以找相关的文章看看，或者我也可以写一篇~~dog。

例如两个类

public class Father {



    public Father(){

        System.out.println("father");

    }

}

public class Son extends Father{



    public static void main(String[] args) {

        Son son = new Son();

    }

}

创建Son对象的同时，会执行Father构造器。也就会打印出father这句话。

那么这个循环操作就是我们要找的循环操作了。

总结

keySet->iterator()->KeyIterator->HashIterator

大家想更清楚了解这个entry是什么？可以看我的HashMap文章~。文章如果存在错误，欢迎大家评论区指正~~

前言

本文不讨论对错，只讲骚操作。

有的方法看看就好，知道可以这么用，但是否应用到实际开发中，那就仁者见仁，智者见智了。

一万个读者就会有一万个哈姆雷特，希望这篇文章能够给您带来一些思考。

耐心看完，你一定会有所收获。

正文

@onX

例如 onConstructor, oMethod, 和 onParam 允许你在生成的代码中注入自定义的注解。一个常见的用例是结合 Spring 的 @Autowired。

在 Spring 的组件（如 @Service、@Controller、@Component、@Repository 等）中使用 @RequiredArgsConstructor(onConstructor = @__(@Autowired))，可以让 Lombok 在生成构造函数时也加上 @Autowired 注解，这样，Spring 就可以自动注入所需的依赖。

例如下面这段代码

@Service

@RequiredArgsConstructor(onConstructor = @__(@Autowired))

public class MyService {

    private final AnotherService anotherService;

}

上述代码片段使用 Lombok 和 Spring 注解，Lombok 会为其生成以下代码

@Service

public class MyService {

    private final AnotherService anotherService;



    @Autowired

    public MyService(AnotherService anotherService) {

        this.anotherService = anotherService;

    }

}

从生成的代码中可以看出：

• 为 MyService 生成了一个构造函数，该构造函数接受一个 AnotherService 类型的参数。


• 由于构造函数上有 @Autowired 注解，Spring 会自动查找合适的 AnotherService bean 实例并注入到 MyService 中。

这种方式结合了 Lombok 的自动代码生成功能和 Spring 的依赖注入功能，使得代码更为简洁。

但是，使用此技巧时要确保团队成员都理解其背后的含义，以避免混淆。

@Delegate

@Delegate可以让你的类使用其他类的方法，而不需要自己写代码。

比如，你有一个类叫做A，它有一个方法叫做sayHello()，你想让另一个类B也能用这个方法，那就可以在B类中加上一个A类型的字段，并在这个字段上加上@Delegate注解，这样，B类就可以直接调用sayHello()方法，就像它是自己的方法一样。看个例子：

// 一个类，有一个方法

public class A {

    public void sayHello() {

        System.out.println("Hello");

    }

}



// 一个类，委托了A类的方法

public class B {

    @Delegate // 委托A类的方法

    private A a = new A();



    public static void main(String[] args) {

        B b = new B();

        b.sayHello(); // 调用A类的方法

    }

}

这样写最大的好处就是可以避免类的层次过深或者耦合过紧，提高代码的可读性和可维护性，各种继承来继承去是真的看得头疼。

@Cleanup

@Cleanup可以自动管理输入输出流等各种需要释放的资源，确保安全地调用close方法。

它的使用方法是在声明的资源前加上@Cleanup，例如：

@Cleanup InputStream in = new FileInputStream("some/file");

这样，当你的代码执行完毕后，Lombok会自动在一个try-finally块中调用in.close()方法，释放资源。

如果要释放资源的方法名不是close，也可以指定要调用的方法名，例如：

@Cleanup("release") MyResource resource = new MyResource();

Lombok会自动在try-finally块中调用resource.release()方法，释放资源。

可以看到，这比手动写try-finally要简洁得太多了，只要使用@Cleanup就能管理任何有无参方法的资源，指定正确的方法名即可。

@Singular 和 @Builder 组合

@Builder让你的类支持链式构造，而@Singular让集合类型字段可以更方便的维护。

@Singular注解可以用在集合类型的字段上，它会生成两个方法，一个是添加单个元素的方法，一个是添加整个集合的方法。这两个方法可以和 @Builder 生成的其他方法一起链式调用，给你的类的所有字段赋值。

这么讲可能有点懵，直接看示例:

@Data

@Builder

public class User {

    private String name;

    private int age;

    @Singular

    private List<String> hobbies;

}



// 使用 @Builder 和 @Singular 生成的方法

User user = User.builder()

    .name("练习时长两年半")

    .age(28)

    .hobby("篮球") // 添加单个元素

    .hobby("唱歌") // 添加单个元素

    .hobbies(Arrays.asList("跳舞", "其他")) // 添加整个集合

    .build(); // 构造 User 对象

可以看出，使用 @Singular 注解的好处是，你可以灵活地添加集合类型的字段，而不需要自己创建和初始化集合对象。

另外，使用 @Singular 注解生成的集合字段，在调用 build() 方法后，会被转换为不可变的集合，这样可以保证对象的不变性和线程安全性。你也可以使用 clear() 方法来清空集合字段，例如：

User user = User.builder()

    .name("签")

    .age(28)

    .hobby("说唱")

    .hobby("跳舞")

    .clearHobbies() // 清空集合字段

    .hobby("踩缝纫机") // 重新添加元素

    .build();

但需要注意的是，如果你的类继承了一个父类，那么 @Builder 只会生成当前类的字段和参数，不包括父类的。

结尾

请注意，尽管 Lombok 提供了许多方便的功能，但过度使用或不当使用可能会导致代码难以理解和维护。

因此，在使用这些功能时，务必始终保持审慎，并且要充分考虑其影响。

Spring Event事件订阅框架，被网上一些人快吹上天了，然而我们在新项目中引入后发现，这个框架缺陷很多，玩玩可以，千万不要再公司项目中使用。还不如自己手写一个监听者设计模式，那样更稳定、可靠。

之前我已经被Spring Event（事件发布订阅组件）坑过一次。那次是在服务关闭期间，有请求未处理完成，当调用Spring Event时，出现异常。

根源是：Spring关闭期间，不得调用GetBean，也就是无法使用Spring Event 。详情点击这里查看

然而新项目大量使用了Spring Event，在另一个Task服务还未来得及移除Spring Event的情况下，出现了类似的问题。

当领导听说新引入的Spring Event再次出现问题时，非常愤怒，因为一个月内出现了两次故障。在复盘会议上，差点爆粗口。

在上线过程中，丢消息了？

“五哥，你看一眼钉钉给你发的监控截图，线上好像有丢消息？” 旁边同事急匆匆的跟我说。

“线上有问题？强哥在上线，我让他先暂停下~”，于是我赶紧通知强哥，先暂停发布。优先排查线上问题~

怎么会有问题呢？我有点意外，正好我和强哥各有代码上线，我只改动很小一段代码。我对这次代码变更很自信，坚信不会有问题，所以我并没有慌乱和紧张。搁之前，我的小心脏早就怦怦跳了！

诡异的情况

出现问题的业务逻辑是 消费A 消息，经过业务处理后，再发送B消息。

从线上监控和日志分析，Task服务收到了 A 消息，然后处理失败了。诡异之处是没有任何异常日志和异常打点，仿佛凭空消失了。

分析代码分支后，我和同事十分确信，任何异常退出的代码分支都有打印异常日志和上报异常监控打点，出现异常不可能不留一丝痕迹。

正当陷入困境之时，我们发现蹊跷之处。“丢消息”的时间只有 3秒钟，之后便恢复正常。问题出在启动阶段，消息A进入Task服务，服务还未完全发布完成时，导致不可预测的情况发生。

当分析Spring 源代码以后，我们发现原因出在 Spring Event……

在详细说明问题根源前，我简单介绍一下 SpringEvent使用，熟悉它的读者，可以自行跳过。

Spring Event的简单使用

声明事件

自定义事件需要继承Spring ApplicationEvent。我选择使用泛型，支持子类可以灵活关联事件的内容。

public class BaseEvent<T> extends ApplicationEvent {

    private final T data;

    

    public BaseEvent(T source) {

        super(source);

        this.data = source;

    }



    public T getData() {

        return data;

    }

}

发布事件

使用Spring上下文 ApplicationContext发布事件

applicationContext.publishEvent(new BaseEvent<>(param));

Idea为Spring提供了跳转工具，点击绿色按钮位置，就可以 跳转到事件的监听器列表。

监听事件

监听器只需要 在方法上声明为 EventListener注解，Spring就会自动找到对应的监听器。Spring会根据方法入参的事件类型和 发布的事件类型 自动匹配。

@EventListener

public void handleEvent(BaseEvent<PerformParam> event) {

    //消费事件

}

服务启动阶段，Spring Event 注册严重滞后

在Kafka 消费逻辑中，通过Spring Event发布事件，业务逻辑都封装在 Event Listenr 中。经过分析和验证后，我们终于发现问题所在。

当Kafka 消费者已经开始消费消息，但Spring Event 监听者还没有注册到Spring ApplicationContext中， 所以Spring Event 事件发布后，没有Event Listener消费该事件。3秒钟以后，Event Listener被注册到Spring后，异常就消失了。

问题根源在：Event Listener 注册的时间点滞后于 init-method 的时间点！

init-method ——— Kafka 开始监听的时间点

Kafka 消费者的启动点 在 Spring init-method中，例如下面的 XML中，init-method 声明 HelloConsumer 的初始化方法为 init方法。在该方法中注册到Kafka中，抢占分片，开始消费消息。

<bean id="kafkaConsumer" class="com.helloworld.KafkaConsumer" init-method="init" destroy-method="destroy">

如果在init-method 方法中，成功注册到Kafka，抢占到分片，然而 Spring Event Listener还未注册到Spring ，就会 “Spring事件丢失” 的现象。

EventListener注册到Spring 的时间点

在Spring的启动过程中，EventListener 的启动点滞后于 init-method 。如下图Spring的启动顺序所示。

其中init-method在InitializingBean中被触发，而 EventListener 在 SmartInitializingSingleton 中初始化。由于启动顺序的先后关系，当init-method的执行时间较长时（例如连接超时），就会出现Kafka已开始消费，但EventListener还未注册的问题。

Spring 启动顺序

InitializingBean 的初始化代码

通过分析 Spring源代码。InitializingBean 阶段， invokeInitMethod 会执行init-method方法，Kafka消费者就是在init-method 执行完成后开始消费kafka消息。

SmartInitializingSingleton

继续分析Spring源代码。 EventListenerMethodProcessor 是 SmartInitializingSingleton 子类，该类负责解析Spring 中所有的Bean，如果有方法添加EventListener注解，则将 EventListener方法 注册到 Spring 中

以下是代码截图

Spring Event很好，我劝你别用

通过代码分析可以发现，在Spring中，init-method方法会先执行，然后才会解析和注册Event Listener。因此，在消费Kafka和注册EventListener之间存在一个时间间隔，如果在这期间发布了Spring Event，该事件将无法被消费。

通常情况下，这个时间间隔非常短暂，但是当init-method执行较慢时，比如Kafka消费者 A 初始化很快，但是Kafka消费者 B 建立连接超时导致init-method执行时间较长，就会出现问题。在这段时间内，Kafka消费者 A 发布的Spring事件无法被消费。

尽管这不是一个稳定必现的问题，但是当线上流量较大时，它发生的概率会增加，后果也会更严重。我们在上线3个月后，线上环境才首次遇到这个问题。

在《服务关闭期，Spring Event消费失败》这篇文章中，有读者评论提到了这个问题。

有朋友说： 这和spring event有什么关系，自己实现一套，不也有同样的问题吗？关键是得优雅停机啊!

他所说的是正确的，如果服务能够完美地进行优雅发布，即使是在大流量场景下，Spring Event也不会出现问题。

一般情况下，公司的项目通常会在 init-method 方法中，统一初始化消息队列 MQ 消费者。如果想要安全地使用Spring Event，必须等到Spring完全发布完成之后才能初始化 Kafka 消费者。

对于公司的项目来说，稳定性非常重要。引入 SpringEvent 前，一定要确保服务的入口流量在正确的时点开启。

今天说说如何排查线上问题，首先声明如果想看什么cpu优化。jvm优化的，我这不适合，我这属于广大底层人士的，纯纯的CRUD，没那么多的性能优化；

开干

报错信息的问题

首先说一个报错信息的问题：对于线上显而易见的界面提示错误，我们要完全避免不要将后台的报错打到前台界面上来，不要将后台的报错打到前台界面上来，不要将后台的报错打到前台界面上来，重要的说三遍，我看到很多线上生产系统报出java报错信息和php报错信息了；外人来看可能看不懂，觉得炫酷，内行人看简直了，垮diao；类似于我找的这个网图

如何排查问题

再说下我们开发人员前后端都写的情况下如何排查问题，对于前后端都开发的人员其实避免了很多扯皮的事情，也少了很多沟通的问题，如果我们环境点击报错，我们可以

如果我们是只写后端，分离项目的那种，那咱们就是加强沟通，和气生财，一切问题出在我后端，前端都是完美的，来问题了你先排查起来，确定没问题了，再去告诉项目大哥，让前端兄弟排查一下，有些新手可能会问为什么不让前端先排查，这个其实不该问，只要是前后端分离的，业务层其实都是摆在后端的，而问题大部分是出在业务上的，所以后端干就完了；

如果我们使用了一些中间件，要没事带关注这些玩意，有时候大家共用的Redis，你不知道别人怎么操作，然后Redis崩了，你能怎么办，如果你是业务前置部门，虽然与你无瓜，但客户的感知就是你报错了，别人躲在后面到不了那一步，所以你得去各方联系重启机器；

项目执行过程真的报oom了呢，那你必须去生产环境捞日志，找到位置，看看机器配置，看看项目执行占用资源情况，纯小白方式直接top命令查看，资源的确给的少了，那么我们启动的时候调整下jvm参数，把它调大，如果是代码执行循环导致的，那么我们就得优化代码，如果是执行任务之类的，比如给个无界队列，那么队列也会把数据撑爆，这时候我们也需要调整业务逻辑，（**记住，队列撑爆内存千万别直接把队列弄成有界的，一定要去沟通怎么优化，得到认可才能干，我们开发对于业务场景是没有产品经理清晰的**）这种挤爆jvm的不是那么多见，但的确很长见识的；

部署打包

排查完、修改完我们就要打包了，其实我特别不建议本地打包那种方式（应该禁止），万一哪个卧龙本地打包后认为活结束了然后忘了提交，然后他离职了然后电脑重置然后over；不管有意无意，环节得控制好我在第一篇就说了，避免后期维护压力，要控制好每一个环节，其实很简单，代码上传git或者svn，用jenkins来打，Jenkins还会记录每一次的打包时间，然后下载发给生产，我觉得比本地打包优秀多了；

还有就是我们上生产的配置文件尽量读取服务器上的配置，不要和打包一起，你的项目可能部署在很多地方用，单独的配置避免了频繁的找文件，如果需要直接生产copy一份然后修改再上传，

ok！完成

四、总结

我也曾是个快乐的童鞋，也有过崇高的理想，直到我面前堆了一座座山，脚下多了一道道坑，我。。。。。。！

大家好，我是程序员鱼皮。

不论在企业、毕设还是个人练手项目中，很多同学或多或少都会涉及微信相关生态的开发，例如微信支付、开放平台、公众号等等。

一般情况下，我们需要到官网查阅这些模块对应的 API 接口，自己编写各种对接微信服务器的代码，结果很多时间都花在了看文档和理解流程上。

好在，某位大佬开源了一个 WxJava 库，它可以让我们更高效快速地开发微信相关的功能。

什么是 WxJava？

WxJava 是一个开箱即用的 SDK，封装了微信生态后端开发绝大部分的 API 接口为现成的方法，包括微信支付、开放平台、小程序、企业微信、公众号等。我们开发时直接调用这个 SDK 提供的方法即可，同时作者针对这个 SDK 还提供了很多接入的 Demo，大部分场景跟着 demo 就能很快上手，非常高效！不需要深入阅读微信开发者官方文档，也能学会微信开发。

这个项目在 GitHub 上 已经有 29.1k 的 star ，社区活跃，且在持续维护更新中。

下面我会通过一个实战案例《公众号的菜单管理功能》，带大家入门 WxJava。

公众号的菜单管理开发实战

1、功能介绍

正常情况下，公众号的管理员可以在公众号网页后台来编辑菜单，例如下面这个页面：

上图中，我在菜单栏分别添加了三个按钮：主菜单一、点击事件、主菜单三。

用户点击 主菜单一 后，就会打开我们设置的跳转网页地址。

上图的 url 仅为演示，实际仅能填写跟公众号相关的网址。

用户点击 点击事件 后，就会自动回复一条消息：您点击了菜单。

你可能会好奇了：公众号网页后台都自带了菜单管理能力，我们还开发什么？

举个例子，如果我们希望用户点了菜单后，调用我们的后端完成新用户注册，就必须要自定义菜单了，因为需要对接我们自己的后端服务器。

而一旦你在后台配置了自己的服务器，就无法使用公众号自带的网页后台来管理菜单和自动回复了，如图：

这种情况下，就只能完全自己在后端写代码来实现这些功能。

2、开发实战

接下来我们用 WxJava 提供的 SDK，通过代码来实现上述同样的功能。

首先，我们需要在 maven 中引入 sdk：

<dependency>

   <groupId>com.github.binarywang</groupId>

   <artifactId>wx-java-mp-spring-boot-starter</artifactId>

   <version>4.4.0</version>

</dependency>

然后在配置文件中添加公众号的 appId 和 appSecret 配置：

按照 WxJava 的规则，编写一个配置类，构建 WxMpService 的 Bean 实例，注入到 Spring 容器中。

上图中的 WxMpService 就是 WxJava 提供的操作微信公众号相关服务的工具类。

接下来，就可以直接创建菜单啦！示例代码如下图：

再次备注：对应 url 内容填写仅为演示，实际 url 对应的网址必须是当前公众号的内容

执行上述代码，其实就可以配置菜单了，你甚至感受不到跟微信服务器 “打交道” 的流程。

这里再简单介绍下菜单二的点击事件，如上面演示，点击 点击事件 公众号会自动回复：“您点击了菜单”。

这个动作被定义为一个叫 CLICK_MENU_KEY 的 key，当用户点击这个按钮后，公众号就会向我们部署的后端服务发送这个事件 key，根据 key 的内容可以执行不同的动作，例如上面说的回复一段文字。

我们仅需把这个 key 绑定到路由上，当触发这个事件就调用对应的 handler 即可，典型的事件驱动设计~

EventHandler 的动作就是返回 “您点击了菜单” 这段文字：

3、其他功能演示

再举例个小功能，如果我们要删除菜单怎么办呢？

非常简单，可以先调用获取菜单的方法：

WxMenu wxMenu = wxMpService.getMenuService().menuGet();

然后根据菜单 ID 就可以调用删除方法来删除菜单：

wxMpService.getMenuService().menuDelete(menuId);

如果要修改菜单，可以再次调用 menuCreate 直接覆盖即可。

最后

利用 WxJava 我们已经实现了菜单的管理，可以看到接口定义非常清晰，使用起来也很方便。当然，以上只是个 Demo，实际企业中如果要操作公众号菜单，不可能每次都是手动执行代码，而是会有一个对应的公众号管理前端，或者再省点事，直接用接口文档来调用操作菜单的接口。感兴趣的同学可以自己实现~

总之希望大家通过这篇教程能够明白，微信相关的开发，并没有那么难，多去做一些调研、多主动搜索一些方案，你会发现很多路前人已经帮你打通了！

可访问我的 Github：github.com/liyupi ，了解更多技术和项目内容。

昨天写了一篇文章《小细节，大问题。分享一次代码优化的过程》，里面提到了list.sort()和list.strem().sorted()排序的差异。

说到list sort()排序比stream().sorted()排序性能更好。

但没说到为什么。

有朋友也提到了这一点。

本文重新开始，先问是不是，再问为什么。

真的更好吗？

先简单写个demo

List userList = new ArrayList<>();

        Random rand = new Random();

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

            userList.add(rand.nextInt(1000));

        }

        List userList2 = new ArrayList<>();

        userList2.addAll(userList);



        Long startTime1 = System.currentTimeMillis();

        userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList());

        System.out.println("stream.sort耗时："+(System.currentTimeMillis() - startTime1)+"ms");



        Long startTime = System.currentTimeMillis();

        userList.sort(Comparator.comparing(Integer::intValue));

        System.out.println("List.sort()耗时："+(System.currentTimeMillis()-startTime)+"ms");

输出

stream.sort耗时：62ms

List.sort()耗时：7ms

由此可见list原生排序性能更好。

能证明吗？

证据错了。

再把demo变换一下，先输出stream.sort

List userList = new ArrayList<>();

        Random rand = new Random();

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

            userList.add(rand.nextInt(1000));

        }

        List userList2 = new ArrayList<>();

        userList2.addAll(userList);



        Long startTime = System.currentTimeMillis();

        userList.sort(Comparator.comparing(Integer::intValue));

        System.out.println("List.sort()耗时："+(System.currentTimeMillis()-startTime)+"ms");



        Long startTime1 = System.currentTimeMillis();

        userList2.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList());

        System.out.println("stream.sort耗时："+(System.currentTimeMillis() - startTime1)+"ms");

此时输出变成了

List.sort()耗时：68ms

stream.sort耗时：13ms

这能证明上面的结论错误了吗？

都不能。

两种方式都不能证明什么。

使用这种方式在很多场景下是不够的，某些场景下，JVM会对代码进行JIT编译和内联优化。

Long startTime = System.currentTimeMillis();

...

System.currentTimeMillis() - startTime

此时，代码优化前后执行的结果就会非常大。

基准测试是指通过设计科学的测试方法、测试工具和测试系统，实现对一类测试对象的某项性能指标进行定量的和可对比的测试。

基准测试使得被测试代码获得足够预热，让被测试代码得到充分的JIT编译和优化。

下面是通过JMH做一下基准测试,分别测试集合大小在100，10000，100000时两种排序方式的性能差异。

import org.openjdk.jmh.annotations.*;

import org.openjdk.jmh.infra.Blackhole;

import org.openjdk.jmh.results.format.ResultFormatType;

import org.openjdk.jmh.runner.Runner;

import org.openjdk.jmh.runner.RunnerException;

import org.openjdk.jmh.runner.options.Options;

import org.openjdk.jmh.runner.options.OptionsBuilder;



import java.util.*;

import java.util.concurrent.ThreadLocalRandom;

import java.util.concurrent.TimeUnit;

import java.util.stream.Collectors;



@BenchmarkMode(Mode.AverageTime)

@OutputTimeUnit(TimeUnit.MICROSECONDS)

@Warmup(iterations = 2, time = 1)

@Measurement(iterations = 5, time = 5)

@Fork(1)

@State(Scope.Thread)

public class SortBenchmark {



    @Param(value = {"100", "10000", "100000"})

    private int operationSize; 





    private static List arrayList;



    public static void main(String[] args) throws RunnerException {

        // 启动基准测试

        Options opt = new OptionsBuilder()

                .include(SortBenchmark.class.getSimpleName()) 

                .result("SortBenchmark.json")

                .mode(Mode.All)

                .resultFormat(ResultFormatType.JSON)

                .build();

        new Runner(opt).run(); 

    }



    @Setup

    public void init() {

        arrayList = new ArrayList<>();

        Random random = new Random();

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

            arrayList.add(random.nextInt(10000));

        }

    }





    @Benchmark

    public void sort(Blackhole blackhole) {

        arrayList.sort(Comparator.comparing(e -> e));

        blackhole.consume(arrayList);

    }



    @Benchmark

    public void streamSorted(Blackhole blackhole) {

        arrayList = arrayList.stream().sorted(Comparator.comparing(e -> e)).collect(Collectors.toList());

        blackhole.consume(arrayList);

    }



}

性能测试结果：

可以看到，list sort()效率确实比stream().sorted()要好。

为什么更好？

流本身的损耗

java的stream让我们可以在应用层就可以高效地实现类似数据库SQL的聚合操作了，它可以让代码更加简洁优雅。

但是，假设我们要对一个list排序，得先把list转成stream流，排序完成后需要将数据收集起来重新形成list，这部份额外的开销有多大呢？

我们可以通过以下代码来进行基准测试

import org.openjdk.jmh.annotations.*;

import org.openjdk.jmh.infra.Blackhole;

import org.openjdk.jmh.results.format.ResultFormatType;

import org.openjdk.jmh.runner.Runner;

import org.openjdk.jmh.runner.RunnerException;

import org.openjdk.jmh.runner.options.Options;

import org.openjdk.jmh.runner.options.OptionsBuilder;



import java.util.ArrayList;

import java.util.Comparator;

import java.util.List;

import java.util.Random;

import java.util.concurrent.TimeUnit;

import java.util.stream.Collectors;



@BenchmarkMode(Mode.AverageTime)

@OutputTimeUnit(TimeUnit.MICROSECONDS)

@Warmup(iterations = 2, time = 1)

@Measurement(iterations = 5, time = 5)

@Fork(1)

@State(Scope.Thread)

public class SortBenchmark3 {



    @Param(value = {"100", "10000"})

    private int operationSize; // 操作次数





    private static List arrayList;



    public static void main(String[] args) throws RunnerException {

        // 启动基准测试

        Options opt = new OptionsBuilder()

                .include(SortBenchmark3.class.getSimpleName()) // 要导入的测试类

                .result("SortBenchmark3.json")

                .mode(Mode.All)

                .resultFormat(ResultFormatType.JSON)

                .build();

        new Runner(opt).run(); // 执行测试

    }



    @Setup

    public void init() {

        // 启动执行事件

        arrayList = new ArrayList<>();

        Random random = new Random();

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

            arrayList.add(random.nextInt(10000));

        }

    }



    @Benchmark

    public void stream(Blackhole blackhole) {

        arrayList.stream().collect(Collectors.toList());

        blackhole.consume(arrayList);

    }



    @Benchmark

    public void sort(Blackhole blackhole) {

        arrayList.stream().sorted(Comparator.comparing(Integer::intValue)).collect(Collectors.toList());

        blackhole.consume(arrayList);

    }

 

}