在日常业务开发中，会通过使用where 1=1来简化动态 SQL语句的拼接，有人说where 1=1会影响性能，也有人说不会，到底会不会影响性能？本文将从 MySQL的官方资料来进行分析。

动态拼接 SQL的方法

在 Mybatis中，动态拼接 SQL最常用的两种方式：使用 where 1=1 和 使用标签。

使用where 1=1

使用过 iBATIS的小伙伴应该都知道：在 iBATIS中没有标签，动态 SQL的处理相对较为原始和复杂，因此使用where 1=1这种写法的用户很大一部分是还在使用 iBATIS 或者是从 iBATIS过度到 Mybatis。

如下示例，通过where 1=1来动态拼接有效的 if语句：

<select id="" parameterType = "">

    SELECT * FROM user 

    WHERE 1=1

    <if test="name != null and name != ''">

        AND name = #{name}

    </if>

    <if test="age != null ">

        AND age = #{age }

    </if>

</select>

使用标签

Mybatis提供了标签，标签只有在至少一个 if条件有值的情况下才去生成 where子句，若 AND或 OR前没有有效语句，where元素会将它们去除，也就是说，如果 Mybatis通过标签动态生成的语句为where AND name = '111'，最终会被优化为where name = '111'。

标签使用示例如下：

<select id="" parameterType = "">

    SELECT * FROM user 

    <where>

        <if test="name != null and name != ''">

           AND name = #{name}

        </if>

        <if test="age != null">

           AND age = #{age}

        </if>

    </where>

</select>

标签是在 MyBatis中引入的，所以，很多一开始就使用 MyBatis的用户对这个标签使用的比较多。

性能影响

where 1=1到底会不会影响性能？我们可以先看一个具体的例子：

说明：示例基于 MySQL 8.0.30

可以使用如下指令查看 MySQL版本：

SELECT VERSION();

场景：基于一张拥有 100多万条数据的user表，根据name进行查询，

查看表结构和表的总数据，如下图：

下面，通过执行两条 SQL查询语句（一条带有 1=1）：

select * from user where name = 'name-96d1b3ce-1a24-4d47-b686-6f9c6940f5f6';

select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

对比两条 SQL执行的结果，可以发现它们消耗的时间几乎相同，因此，看起来where 1=1对整体的性能似乎并不影响。

为了排除一次查询不具有代表性，我们分别对两条 SQL语句查询 100遍，然后计算平均值：

SET PROFILING = 1;

DO SLEEP(0.001); -- 确保每次查询之间有足够时间间隔



SET @count = 0;

WHILE @count < 100 DO

select * from user where name = 'name-96d1b3ce-1a24-4d47-b686-6f9c6940f5f6';

-- or

select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

SET @count = @count + 1;

END WHILE;    



SHOW PROFILES;

两条 SQL分别执行 100次后，最终也发现它们的平均值几乎相同，因此，上述示例似乎证明了 where 1=1 对整体的性能并没有不影响。

为什么没有影响？是不是 MySQL对 1=1进行了优化？

为了证明猜想，我们借助show warnings命令来查看信息，在 MySQL中，show warnings命令用于显示最近执行的 SQL语句产生的警告、错误或通知信息。它可以帮助我们了解语句执行过程中的问题。如下示例：

explain select * from user where 1=1 and name = 'name-f692472e-40de-4053-9498-54b9800e9fb1';

show warnings;

将上述示例的 warnings信息摘出来如下：

/* select#1 */ select `yuanjava`.`user`.`id` AS `id`,

      `yuanjava`.`user`.`name` AS `name`,

      `yuanjava`.`user`.`age` AS `age`,

      `yuanjava`.`user`.`sex` AS `sex`,

      `yuanjava`.`user`.`created_at` AS `created_at` 

from `yuanjava`.`user` 

where (`yuanjava`.`user`.`name` = 'name-f692472e-40de-4053-9498-54b9800e9fb1')

从 warnings信息可以看出：1=1已经被查询优化器优化掉，因此，对整体的性能影响并不大。

那么，有没有 MySQL的官方资料可以佐证 where 1=1确实被优化了？

答案：有！MySQL有一种 Constant-Folding Optimization（常量折叠优化）的功能。

Constant-Folding Optimization

MySQL的优化器具有一项称为 Constant-Folding Optimization（常量折叠优化）的功能，可以从查询中消除重言式表达式。Constant-Folding Optimization 是一种编译器的优化技术，用于优化编译时计算表达式的常量部分，从而减少运行时的计算量，换句话说：Constant-Folding Optimization 是发生在编译期，而不是引擎执行期间。

对于上述表达的"重言式表达式"又是什么呢？

重言式

重言式（Tautology ）又称为永真式，它的汉语拼音为：[Chóng yán shì]，是逻辑学的名词。命题公式中有一类重言式，如果一个公式，对于它的任一解释下其真值都为真，就称为重言式（永真式）。

其实，重言式在计算机领域也具有重要应用，比如"重言式表达式"（Tautological expression），它指的是那些总是为真的表达式或逻辑条件。

在 SQL查询中，重言式表达式是指无论在什么情况下，结果永远为真，它们通常会被优化器识别并优化掉，以提高查询效率。例如，如果 where中包含 1=1 或 A=A 这种重言式表达式，它们就会被优化器移除，因为对查询结果没有实际影响。如下两个示例：

SELECT * from user where 1=1 and name = 'xxx';

-- 被优化成

SELECT * from user where name = 'xxx'；



SELECT id, name, salary * (1 + 0.05 * 2) AS real_salary FROM employees;

-- 优化成(1 + 0.05 * 2 被优化成 1.1)

SELECT id, name, salary * 1.1 AS real_salary FROM employees;

另外，通过下面 MySQL架构示意图可以看出：优化器是属于 MySQL的 Server层，因此，Constant-Folding Optimization功能支持受 MySQL Server的版本影响。

查阅了 MySQL的官方资料，Constant-Folding Optimization 从 MySQL5.7版本开始引入，至于 MySQL5.7以前的版本是否具备这个功能，还有待考证。

如何选择？

where 1=1 和 标签 两种方案，该如何选择？

• 如果 MySQL Server版本大于等于 5.7，两个随便选，或者根据团队的要求来选；


• 如果 MySQL Server版本小于 5.7，假如使用的是 MyBatis，建议使用 标签，如果使用的还是比较老的 iBATIS，只能使用where 1=1；


• 如果 MySQL Server版本小于 5.7，建议升升级

信息补充：2009年5月，iBATIS从 2.0版本开始更名为 MyBatis， 标签最早出现在MyBatis 3.2.0版本中

总结

where 1=1和 标签到底会不会影响性能，这个问题在网上已经出现了很多次，今天还是想从官方文档来进行说明。本文通过 MySQL的官方资料，加上百万数据的表进行真实测试，得出下面的结论：

• 如果 MySQL Server版本大于等于 5.7，两个随便选，或者根据团队的要求来选；


• 如果 MySQL Server版本小于 5.7，假如使用的是 MyBatis，建议使用 标签，如果使用的还是比较老的 iBATIS，只能使用where 1=1；

最后，遇到问题，建议首先查找官方的一手资料，这样才能帮助自己在一条正确的技术道路上成长！

参考资料

MySQL8.0 Constant-Folding Optimization

MySQL5.7 WHERE Clause Optimization

What’s New in MySQL 5.7

1. 背景

今天刷到一篇文章，标题是反射为什么慢，一下子懵逼了，确实没想过这个问题；盲猜了一下是由于反射实际上是做了一个代理的动作，导致执行的效率是小于直接实体类去调用方法的。

2. 文章给出的解释

文章中给出的理由是因为以下4点：

3. 结合实际理解

3.1 第一点分析

首先我们需要知道，java中的反射是一种机制，它可以在代码运行过程中，获取类的内部信息（变量、构造方法、成员方法）；操作对象的属性、方法。
然后关于反射的原理，首先我们需要知道一个java项目在启动之后，会将class文件加载到堆中，生成一个class对象，这个class对象中有一个类的所有信息，通过这个class对象获取类相关信息的操作我们称为反射。

其次是JIT优化技术，首先我们需要知道在java虚拟机中有两个角色，解释器和编译器；这两者各有优劣，首先是解释器可以在项目启动的时候直接直接发挥作用，省去编译的时候，立即执行，但是在执行效率上有所欠缺；在项目启动之后，随着时间推移，编译器逐渐将机器码编译成本地代码执行，减少解释器的中间损耗，增加了执行效率。

我们可以知道JIT优化通常依赖于在编译时能够知道的静态信息，而反射的动态性可能会破坏这些假设，使得JIT编译器难以进行有效的优化。

3.2 第二点

关于第二点，我们直接写一段反射调用对象方法的demo：

@Test

public void methodTest() {

    Class clazz = MyClass.class;



    try {

        //获取指定方法

        //这个注释的会报错 java.lang.NoSuchMethodException

        //Method back = clazz.getMethod("back");

        Method back = clazz.getMethod("back", String.class);

        Method say = clazz.getDeclaredMethod("say", String.class);

        //私有方法需要设置

        say.setAccessible(true);

        MyClass myClass = new MyClass("abc", 99);

        //反射调用方法

        System.out.println(back.invoke(myClass, "back"));



        say.invoke(myClass, "hello world");

    } catch (Exception e) {

        e.printStackTrace();

    }

}

在上面这段代码中，我们调用了一个invoke 方法，并且传了class对象和参数，进入到invoke方法中，我们可以看到invoke方法的入参都是Object类型的，args更是一个Object 数组，这就第二点，关于反射调用过程中的拆装箱。

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

3.3 第三点

关于调用方法需要遍历这点，还是上面那个demo，我们在获取Method 对象的时候是通过调用getMethod、getDeclaredMethod方法，点击进入这个方法的源码，我们可以看到如下代码：

private static Method searchMethods(Method[] methods,

                                    String name,

                                    Class<?>[] parameterTypes)

{

    Method res = null;

    String internedName = name.intern();

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

        Method m = methods[i];

        if (m.getName() == internedName

            && arrayContentsEq(parameterTypes, m.getParameterTypes())

            && (res == null

                || res.getReturnType().isAssignableFrom(m.getReturnType())))

            res = m;

    }



    return (res == null ? res : getReflectionFactory().copyMethod(res));

}

我们可以看到，底层实际上也是将class对象的所有method遍历了一遍，最终才拿到我们需要的方法的，这也就是第二点，执行具体方法的时候需要遍历class对象的方法。

3.4 第四点

第4点说需要对方法和参数进行检查，也就是我们在执行具体的某一个方法的时候，我们实际上是需要校验这个方法是否可见的，如果不可见，我们还需要将这个方法设置为可见，否则如果我们直接调用这个方法的话，会报错。

同时还有一个点，在我们调用invoke方法的时候，反射类会对方法和参数进行一个校验，让我们来看一下源码：

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

我们可以看到还有quickCheckMemberAccess、checkAccess 等逻辑

4. 总结

平时在反射这块用的比较少，也没针对性的去学习一下。在工作之余，还是得保持一个学习的习惯，这样子才不会出现今天这种被一个问题难倒的情况，而且才能产出更多、更优秀的方案。

你好呀，我是歪歪。

前几天我在网上冲浪，看到一个哥们在吐槽，说他工作三年多了，没使用过多线程。

虽然八股文背的滚瓜烂熟，但是没有在实际开发过程中写的都是业务代码，没有使用过线程池，心里还是慌得一比。

我只是微微一笑，这不是很正常吗？

业务代码中一般也使不上多线程，或者说，业务代码中不知不觉你以及在使用线程池了，你再 duang 的一下搞一个出来，反而容易出事。

所以提到线程池的时候，我个人的观点是必须把它吃得透透的，但是在业务代码中少用或者不用多线程。

关于这个观点，我给你盘一下。

Demo

首先我们还是花五分钟搭个 Demo 出来。

我手边刚好有一个之前搭的一个关于 Dubbo 的 Demo，消费者、生产者都有，我就直接拿来用了：

这个 Demo 我也是跟着网上的 quick start 搞的：

cn.dubbo.apache.org/zh-cn/overv…

可以说写的非常详细了，你就跟着官网的步骤一步步的搞就行了。

我这个 Demo 稍微不一样的是我在消费者模块里面搞了一个 Http 接口：

在接口里面发起了 RPC 调用，模拟从前端页面发起请求的场景，更加符合我们的开发习惯。

而官方的示例中，是基于了 SpringBoot 的 CommandLineRunner 去发起调用：

只是发起调用的方式不一样而已，其他没啥大区别。

需要说明的是，我只是手边刚好有一个 Dubbo 的 Demo，随手就拿来用了，但是本文想要表达的观点，和你使不使用 Dubbo 作为 RPC 框架，没有什么关系，道理是通用的。

上面这个 Demo 启动起来之后，通过 Http 接口发起一次调用，看到控制台服务提供方和服务消费方都有对应的日志输出，准备工作就算是齐活儿了：

上菜

在上面的 Demo 中，这是消费者的代码：

这是提供者的代码：

整个调用链路非常的清晰：

来，请你告诉我这里面有线程池吗？

没有！

是的，在日常的开发中，我就是写个接口给别人调用嘛，在我的接口里面并没有线程池相关的代码，只有 CRUD 相关的业务代码。

同时，在日常的开发中，我也经常调用别人提供给我的接口，也是一把梭，撸到底，根本就不会用到线程池。

所以，站在我，一个开发人员的角度，这个里面没有线程池。

合理，非常合理。

但是，当我们换个角度，再看看，它也是可以有的。

比如这样：

反应过来没有？

我们发起一个 Http 调用，是由一个 web 容器来处理这个请求的，你甭管它是 Tomcat，还是 Jetty、Netty、Undertow 这些玩意，反正是个 web 容器在处理。

那你说，这个里面有线程池吗？

在方法入口处打个断点，这个 http-nio-8081-exec-1 不就是 Tomcat 容器线程池里面的一个线程吗：

通过 dump 堆栈信息，过滤关键字可以看到这样的线程，在服务启动起来，啥也没干的情况下，一共有 10 个：

朋友，这不就是线程池吗？

虽然不是你写的，但是你确实用了。

我写出来的这个 test 接口，就是会由 web 容器中的一个线程来进行调用。所以，站在 web 容器的角度，这里是有一个线程池的：

同理，在 RPC 框架中，不管是消费方，还是服务提供方，也都存在着线程池。

比如 Dubbo 的线程池，你可以看一下官方的文档：

cn.dubbo.apache.org/zh-cn/overv…

而对于大多数的框架来说，它绝不可能只有一个线程池，为了做资源隔离，它会启用好几个线程池，达到线程池隔离，互不干扰的效果。

比如参与 Dubbo 一次调用的其实不仅一个线程池，至少还有 IO 线程池和业务线程池，它们各司其职：

我们主要关注这个业务线程池。

反正站在 Dubbo 框架的角度，又可以补充一下这个图片了：

那么问题来了，在当前的这个情况下？

当有人反馈：哎呀，这个服务吞吐量怎么上不去啊？

你怎么办？

你会 duang 的一下在业务逻辑里面加一个线程池吗？

大哥，前面有个 web 容器的线程池，后面有个框架的线程池，两头不调整，你在中间加个线程池，加它有啥用啊？

web 容器，拿 Tomcat 来说，人家给你提供了线程池参数调整的相关配置，这么一大坨配置，你得用起来啊：

tomcat.apache.org/tomcat-9.0-…

再比如 Dubbo 框架，都给你明说了，这些参数属于性能调优的范畴，感觉不对劲了，你先动手调调啊：

你把这些参数调优弄好了，绝对比你直接怼个线程池在业务代码中，效果好的多。

甚至，你在业务代码中加入一个线程池之后，反而会被“反噬”。

比如，你 duang 的一下怼个线程池在这里，我们先只看 web 容器和业务代码对应的部分：

由于你的业务代码中有线程池的存在，所以当接受到一个 web 请求之后，立马就把请求转发到了业务线程池中，由线程池中的线程来处理本次请求，从而释放了 web 请求对应的线程，该线程又可以里面去处理其他请求。

这样来看，你的吞吐量确实上去了。

在前端来看，非常的 nice，请求立马得到了响应。

但是，你考虑过下游吗？

你的吞吐量上涨了，下游同一时间处理的请求就变多了。如果下游跟不上处理，顶不住了，直接就是崩给你看怎么办？

而且下游不只是你一个调用方，由于你调用的太猛，导致其他调用方的请求响应不过来，是会引起连锁反应的。

所以，这种场景下，为了异步怼个线程池放着，我觉得还不如用消息队列来实现异步化，顶天了也就是消息堆积嘛，总比服务崩了好，这样更加稳妥。

或者至少和下游勾兑一下，问问我们这边吞吐量上升，你们扛得住不。

有的小伙伴看到这里可能就会产生一个疑问了：歪师傅，你这个讲得怎么和我背的八股文不一样啊？

巧了，你背过的八股文我也背过，现在我们来温习一下我们背过的八股文。

什么时候使用线程池呢？

比如一个请求要经过若干个服务获取数据，且这些数据没有先后依赖，最终需要把这些数据组合起来，一并返回，这样经典的场景：

用户点商品详情，你要等半天才展示给用户，那用户肯定骂骂咧咧的久走了。

这个时候，八股文上是怎么说的：用线程池来把串行的动作改成并行。

这个场景也是增加了服务 A 的吞吐量，但是用线程池就是非常正确的，没有任何毛病。

但是你想想，我们最开始的这个案例，是这个场景吗？

我们最开始的案例是想要在业务逻辑中增加一个线程池，对着一个下游服务就是一顿猛攻，不是所谓的串行改并行，而是用更多的线程，带来更多的串行。

这已经不是一个概念了。

还有一种场景下，使用线程池也是合理的。

比如你有一个定时任务，要从数据库中捞出状态为初始化的数据，然后去调用另外一个服务的接口查询数据的最终状态。

如果你的业务代码是这样的：

//获取订单状态为初始化的数据(0:初始化 1:处理中 2:成功 3:失败)

//select * from order where order_status=0;

ArrayList initOrderInfoList = queryInitOrderInfoList();

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //捕获异常以免一条数据错误导致循环结束

    try{

        //发起rpc调用

        String orderStatus = queryOrderStatus(orderInfo.getOrderId);

        //更新订单状态

        updateOrderInfo(orderInfo.getOrderId,orderStatus);  

    } catch (Exception e){

        //打印异常

    }

}

虽然你框架中使用了线程池，但是你就是在一个 for 循环中不停的去调用下游服务查询数据状态，是一条数据一条数据的进行处理，所以其实同一时间，只是使用了框架的线程池中的一个线程。

为了更加快速的处理完这批数据，这个时候，你就可以怼一个线程池放在 for 循环里面了：

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //使用线程池

    executor.execute(() -> {

        //捕获异常以免一条数据错误导致循环结束

        try {

            //发起rpc调用

            String orderStatus = queryOrderStatus(orderInfo.getOrderId);

            //更新订单状态

            updateOrderInfo(orderInfo.getOrderId, orderStatus);

        } catch (Exception e) {

            //打印异常

        }

    });

}

需要注意的是，这个线程池的参数怎么去合理的设置，是需要考虑的事情。

同时这个线程池的定位，就类似于 web 容器线程池的定位。

或者这样对比起来看更加清晰一点：

定时任务触发的时候，在发起远程接口调用之前，没有线程池，所以我们可以启用一个线程池来加快数据的处理。

而 Http 调用或者 RPC 调用，框架中本来就已经有一个线程池了，而且也给你提供了对应的性能调优参数配置，那么首先考虑的应该是把这个线程池充分利用起来。

如果仅仅是因为异步化之后可以提升服务响应速度，没有达到串行改并行的效果，那么我更加建议使用消息队列。

好了，本文的技术部分就到这里啦。

下面这个环节叫做[荒腔走板]，技术文章后面我偶尔会记录、分享点生活相关的事情，和技术毫无关系。我知道看起来很突兀，但是我喜欢，因为这是一个普通博主的生活气息。

荒腔走板

不知道你看完文章之后，有没有产生一个小疑问：最开始部分的 Demo 似乎用处并不大？

是的，我最开始构思的行文结构是是基于 Demo 在源码中找到关于线程池的部分，从而引出其实有一些我们“看不见的线程池”的存在的。

原本周六我是有一整天的时间来写这篇文章，甚至周五晚上还特意把 Demo 搞定，自己调试了一番，该打的断点全部打上，并写完 Demo 那部分之后，我才去睡觉的，想得是第二天早上起来直接就能用。

按照惯例周六睡个懒觉的，早上 11 点才起床，自己慢条斯理的做了一顿午饭，吃完饭已经是下午 1 点多了。

本来想着在沙发上躺一会，结果一躺就是一整个下午。期间也想过起来写一会文章，坐在电脑前又飞快的躺回到沙发上，就是觉得这个事情索然无味，当下的那一刻就想躺着，然后无意识的刷手机，原本是拿来写文章中关于源码的部分的时间就这样浪费了。

像极了高中时的我，周末带大量作业回家，准备来个悬梁刺股，弯道超车，结果变成了一睡一天，捏紧刹车。

高中的时候，时间浪费了是真的可惜。

现在，不一样了。

荒腔走板这张图片，就是我躺在沙发上的时候，别人问我在干什么时随手拍的一张。

我并不为躺了一下午没有干正事而感到惭愧，浪费了的时间，才是属于自己的时间。

很久以前我看到别人在做一些浪费时间的事情的时候，我心里可能会嘀咕几句，劝人惜时。

这两年我不会了，允许自己做自己，允许别人做别人。

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

作者：毅航😜

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