• [Arrays.asList（）方法介绍]


• [Arrays.asList（）方法的坑]


• [解决Arrays.asList（）方法的坑]


• [总结]


• [Arrays.asList（）方法介绍]


• [Arrays.asList（）方法的坑]


• [解决Arrays.asList（）方法的坑]


• [总结]

在Java中，我们经常需要将数组转换为List来方便地进行操作。Arrays.asList()方法是一种常见的方式，但是它存在一个不太常见但需要注意的坑。

本文将深入探讨Arrays.asList()的使用，揭示其中的陷阱，并提供解决方案。

[Arrays.asList（）方法介绍]

Arrays.asList()方法是将数组转换为List的方法，它返回一个List对象，但这个List对象并不是java.util.ArrayList对象，而是Arrays内部的ArrayList对象。

Arrays.ArrayList类继承自AbstractList，实现了List接口。它重写了add()、remove()等修改List结构的方法，并将它们直接抛出UnsupportedOperationException异常，从而禁止了对List结构的修改。

具体来说，Arrays.asList()方法返回的是Arrays类中的一个私有静态内部类ArrayList，它继承自AbstractList类，实现了List接口。

Arrays.asList()方法的使用非常简单，只需要将一个数组作为参数传递给该方法即可。例如：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = Arrays.asList(arr);

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：github.com/YunaiV/ruoy…


• 视频教程：doc.iocoder.cn/video/

[Arrays.asList（）方法的坑]

尽管Arrays.asList()方法很方便，但也存在一些坑，其中最常见的一个是：在使用Arrays.asList()方法时，如果对返回的List对象进行修改（例如增加、删除元素），将会抛出"UnsupportedOperationException"异常。

为什么会出现这个异常呢？这是因为Arrays.asList()方法返回的List对象，是一个固定大小的List，不能进行结构上的修改，否则会抛出异常。

下面的代码演示了这个问题：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = Arrays.asList(arr);

list.add("d"); // 抛出 UnsupportedOperationException 异常

上述代码中，我们尝试向List对象中添加一个新的元素"d"，结果会抛出"UnsupportedOperationException"异常。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：github.com/YunaiV/yuda…


• 视频教程：doc.iocoder.cn/video/

[解决Arrays.asList（）方法的坑]

要解决Arrays.asList()方法的坑，我们需要将返回的List对象转换为一个可修改的List对象。有几种方法可以实现这个目标：

[方法一：使用java.util.ArrayList类]

我们可以使用java.util.ArrayList类，将Arrays.asList()方法返回的List对象转换为一个java.util.ArrayList对象，示例如下：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = new ArrayList<>(Arrays.asList(arr));

list.add("d"); // 正常运行

上述代码中，我们首先使用Arrays.asList()方法将一个数组转换为一个List对象，然后使用ArrayList的构造方法，将这个List对象转换为一个java.util.ArrayList对象，最后可以向这个ArrayList对象中添加元素。

[方法二：使用Collections类]

我们也可以使用Collections类提供的静态方法，将Arrays.asList()方法返回的List对象转换为一个可修改的List对象，示例如下：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = new ArrayList<>(Arrays.asList(arr));

Collections.addAll(list, "d"); // 正常运行

通过Collections.addAll()方法，我们可以将数组中的元素逐个添加到一个新的ArrayList对象中，从而实现了可修改性。

[总结]

在使用Arrays.asList()方法时，需要注意返回的List对象是一个固定大小的List，不支持结构上的修改操作。为了避免这个陷阱，我们可以使用java.util.ArrayList或Collections类提供的方法将返回的List对象转换为可修改的List。通过了解这个陷阱并采取相应的解决方案，我们可以安全地将数组转换为List，并避免潜在的异常情况。

不要让Arrays.asList()的陷阱坑了你的代码！

在Java中，我们经常需要将数组转换为List来方便地进行操作。Arrays.asList()方法是一种常见的方式，但是它存在一个不太常见但需要注意的坑。本文将深入探讨Arrays.asList()的使用，揭示其中的陷阱，并提供解决方案。

[Arrays.asList（）方法介绍]

Arrays.asList()方法是将数组转换为List的方法，它返回一个List对象，但这个List对象并不是java.util.ArrayList对象，而是Arrays内部的ArrayList对象。

Arrays.ArrayList类继承自AbstractList，实现了List接口。它重写了add()、remove()等修改List结构的方法，并将它们直接抛出UnsupportedOperationException异常，从而禁止了对List结构的修改。

具体来说，Arrays.asList()方法返回的是Arrays类中的一个私有静态内部类ArrayList，它继承自AbstractList类，实现了List接口。

Arrays.asList() 方法的使用非常简单，只需要将一个数组作为参数传递给该方法即可。例如：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = Arrays.asList(arr);

[Arrays.asList（）方法的坑]

尽管Arrays.asList()方法很方便，但也存在一些坑，其中最常见的一个是：在使用Arrays.asList()方法时，如果对返回的List对象进行修改（例如增加、删除元素），将会抛出"UnsupportedOperationException"异常。

为什么会出现这个异常呢？这是因为Arrays.asList()方法返回的List对象，是一个固定大小的List，不能进行结构上的修改，否则会抛出异常。

下面的代码演示了这个问题：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = Arrays.asList(arr);

list.add("d"); // 抛出 UnsupportedOperationException 异常

上述代码中，我们尝试向List对象中添加一个新的元素"d"，结果会抛出"UnsupportedOperationException"异常。

[解决Arrays.asList（）方法的坑]

要解决Arrays.asList()方法的坑，我们需要将返回的List对象转换为一个可修改的List对象。有几种方法可以实现这个目标：

[方法一：使用java.util.ArrayList类]

我们可以使用java.util.ArrayList类，将Arrays.asList()方法返回的List对象转换为一个java.util.ArrayList对象，示例如下：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = new ArrayList<>(Arrays.asList(arr));

list.add("d"); // 正常运行

上述代码中，我们首先使用Arrays.asList()方法将一个数组转换为一个List对象，然后使用ArrayList的构造方法，将这个List对象转换为一个java.util.ArrayList对象，最后可以向这个ArrayList对象中添加元素。

[方法二：使用Collections类]

我们也可以使用Collections类提供的静态方法，将Arrays.asList()方法返回的List对象转换为一个可修改的List对象，示例如下：

String[] arr = new String[]{"a", "b", "c"};

List<String> list = new ArrayList<>(Arrays.asList(arr));

Collections.addAll(list, "d"); // 正常运行

通过Collections.addAll()方法，我们可以将数组中的元素逐个添加到一个新的ArrayList对象中，从而实现了可修改性。

[总结]

在使用Arrays.asList()方法时，需要注意返回的List对象是一个固定大小的List，不支持结构上的修改操作。为了避免这个陷阱，我们可以使用java.util.ArrayList或Collections类提供的方法将返回的List对象转换为可修改的List。通过了解这个陷阱并采取相应的解决方案，我们可以安全地将数组转换为List，并避免潜在的异常情况。

不要让Arrays.asList()的陷阱坑了你的代码！

前言

  Java 编程语言的每一次重要更新，都引入了许多新功能和改进。 并且在String 类中引入了一些新的方法，能够更好地满足开发的需求，提高编程效率。

示例

1. repeat(int count)

public class StringRepeatExample {

    public static void main(String[] args) {

        String str = "abc";

        String repeatedStr = str.repeat(3);

        System.out.println(repeatedStr);

    }

}

输出结果：

abcabcabc

2. isBlank()

public class StringIsBlankExample {

    public static void main(String[] args) {

        String str1 = "";

        String str2 = " ";

        String str3 = "  \t  ";



        System.out.println(str1.isBlank());

        System.out.println(str2.isBlank());

        System.out.println(str3.isBlank());

    }

}

输出结果：

true

true

true

3. lines()

import java.util.stream.Stream;



public class StringLinesExample {

    public static void main(String[] args) {

        String str = "Hello\nWorld\nJava";

        Stream<String> lines = str.lines();

        lines.forEach(System.out::println);

    }

}

输出结果：

Hello

World

Java

4. strip()

public class StringStripExample {

    public static void main(String[] args) {

        String str1 = "  abc   ";

        String str2 = "\t def \n";

        System.out.println(str1.strip());

        System.out.println(str2.strip());

    }

}

输出结果：

abc

def

5. stripLeading()

public class StringStripLeadingExample {

    public static void main(String[] args) {

        String str1 = "  abc   ";

        String str2 = "\t def \n";

        System.out.println(str1.stripLeading());

        System.out.println(str2.stripLeading());

    }

}

输出结果：

abc

def

6. stripTrailing()

public class StringStripTrailingExample {

    public static void main(String[] args) {

        String str1 = "  abc   ";

        String str2 = "\t def \n";

        System.out.println(str1.stripTrailing());

        System.out.println(str2.stripTrailing());

    }

}

输出结果：

abc

def

7. formatted(Object... args)

public class StringFormattedExample {

    public static void main(String[] args) {

        String str = "My name is %s, I'm %d years old.";

        String formattedStr = str.formatted( "John", 25);

        System.out.println(formattedStr);

    }

}

输出结果：

My name is John, I'm 25 years old.

8. translateEscapes()

public class StringTranslateEscapesExample {

    public static void main(String[] args) {

        String str = "Hello\\nWorld\\tJava";

        String translatedStr = str.translateEscapes();

        System.out.println(translatedStr);

    }

}

输出结果：

Hello

World   Java

9. transform()

public class StringTransformExample {

    public static void main(String[] args) {  

        String str = "hello world";  

        String result = str.transform(i -> i + "！");  

        System.out.println(result);  

    }

}

输出结果：

hello world！

结尾

  如果觉得对你有帮助，可以多多评论，多多点赞哦，也可以到我的主页看看，说不定有你喜欢的文章，也可以随手点个关注哦，谢谢。

  我是不一样的科技宅，每天进步一点点，体验不一样的生活。我们下期见！

前言

作为一名java开发程序员，不知道大家有没有遇到过一些匪夷所思的bug。这些错误通常需要您几个小时才能解决。当你找到它们的时候，你可能会默默地骂自己是个傻瓜。是的，这些可笑的bug基本上都是你忽略了一些基础知识造成的。其实都是很低级的错误。今天，我总结一些常见的编码错误，然后给出解决方案。希望大家在日常编码中能够避免这样的问题。

1. 使用Objects.equals比较对象

这种方法相信大家并不陌生，甚至很多人都经常使用。是JDK7提供的一种方法，可以快速实现对象的比较，有效避免烦人的空指针检查。但是这种方法很容易用错，例如：

Long longValue = 123L;

System.out.println(longValue==123); //true

System.out.println(Objects.equals(longValue,123)); //false

为什么替换==为Objects.equals()会导致不同的结果？这是因为使用==编译器会得到封装类型对应的基本数据类型longValue，然后与这个基本数据类型进行比较，相当于编译器会自动将常量转换为比较基本数据类型, 而不是包装类型。

使用该Objects.equals()方法后，编译器默认常量的基本数据类型为int。下面是源码Objects.equals()，其中a.equals(b)使用的是Long.equals()会判断对象类型，因为编译器已经认为常量是int类型，所以比较结果一定是false。

public static boolean equals(Object a, Object b) {

    return (a == b) || (a != null && a.equals(b));

}

    

public boolean equals(Object obj) {

    if (obj instanceof Long) {

        return value == ((Long)obj).longValue();

    }

    return false;

}

知道了原因，解决方法就很简单了。直接声明常量的数据类型，如Objects.equals(longValue,123L)。其实如果逻辑严密，就不会出现上面的问题。我们需要做的是保持良好的编码习惯。

2. 日期格式错误

在我们日常的开发中，经常需要对日期进行格式化，但是很多人使用的格式不对，导致出现意想不到的情况。请看下面的例子。

Instant instant = Instant.parse("2021-12-31T00:00:00.00Z");

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYY-MM-dd HH:mm:ss")

.withZone(ZoneId.systemDefault());

System.out.println(formatter.format(instant));//2022-12-31 08:00:00

以上用于YYYY-MM-dd格式化, 年从2021 变成了 2022。为什么？这是因为 java 的DateTimeFormatter 模式YYYY和yyyy之间存在细微的差异。它们都代表一年，但是yyyy代表日历年，而YYYY代表星期。这是一个细微的差异，仅会导致一年左右的变更问题，因此您的代码本可以一直正常运行，而仅在新的一年中引发问题。12月31日按周计算的年份是2022年，正确的方式应该是使用yyyy-MM-dd格式化日期。

这个bug特别隐蔽。这在平时不会有问题。它只会在新的一年到来时触发。我公司就因为这个bug造成了生产事故。

3. 在 ThreadPool 中使用 ThreadLocal

如果创建一个ThreadLocal 变量，访问该变量的线程将创建一个线程局部变量。合理使用ThreadLocal可以避免线程安全问题。

但是，如果在线程池中使用ThreadLocal ，就要小心了。您的代码可能会产生意想不到的结果。举个很简单的例子，假设我们有一个电商平台，用户购买商品后需要发邮件确认。

private ThreadLocal currentUser = ThreadLocal.withInitial(() -> null);



private ExecutorService executorService = Executors.newFixedThreadPool(4);



public void executor() {

    executorService.submit(()->{

        User user = currentUser.get();

        Integer userId = user.getId();

        sendEmail(userId);

    });

}

如果我们使用ThreadLocal来保存用户信息，这里就会有一个隐藏的bug。因为使用了线程池，线程是可以复用的，所以在使用ThreadLocal获取用户信息的时候，很可能会误获取到别人的信息。您可以使用会话来解决这个问题。

4. 使用HashSet去除重复数据

在编码的时候，我们经常会有去重的需求。一想到去重，很多人首先想到的就是用HashSet去重。但是，不小心使用 HashSet 可能会导致去重失败。

User user1 = new User();

user1.setUsername("test");



User user2 = new User();

user2.setUsername("test");



List users = Arrays.asList(user1, user2);

HashSet sets = new HashSet<>(users);

System.out.println(sets.size());// the size is 2

细心的读者应该已经猜到失败的原因了。HashSet使用hashcode对哈希表进行寻址，使用equals方法判断对象是否相等。如果自定义对象没有重写hashcode方法和equals方法，则默认使用父对象的hashcode方法和equals方法。所以HashSet会认为这是两个不同的对象，所以导致去重失败。

5. 线程池中的异常被吃掉

ExecutorService executorService = Executors.newFixedThreadPool(1);

executorService.submit(()->{

    //do something

    double result = 10/0;

});

上面的代码模拟了一个线程池抛出异常的场景。我们真正的业务代码要处理各种可能出现的情况，所以很有可能因为某些特定的原因而触发RuntimeException 。

但是如果没有特殊处理，这个异常就会被线程池吃掉。这样就会导出出现问题你都不知道，这是很严重的后果。因此，最好在线程池中try catch捕获异常。

总结

本文总结了在开发过程中很容易犯的5个错误，希望大家养成良好的编码习惯。

我们在开发过程中经常需要接收前端传来的文件，通常需要处理MultipartFile格式的文件。今天来介绍一下MultipartFile和File怎么进行优雅的互转。

前言

首先来区别一下MultipartFile和File:

• MultipartFile是 Spring 框架的一部分，File是 Java 标准库的一部分。


• MultipartFile主要用于接收上传的文件，File主要用于操作系统文件。

MultipartFile转换为File

使用 transferTo

这是一种最简单的方法，使用MultipartFile自带的transferTo 方法将MultipartFile转换为File，这里通过上传表单文件，将MultipartFile转换为File格式，然后输出到特定的路径，具体写法如下。

使用 FileOutputStream

这是最常用的一种方法，使用 FileOutputStream 可以将字节写入文件。具体写法如下。

使用 Java NIO

Java NIO 提供了文件复制的方法。具体写法如下。

File装换为MultipartFile

从File转换为MultipartFile 通常在测试或模拟场景中使用，生产环境一般不这么用，这里只介绍一种最常用的方法。

使用 MockMultipartFile

在转换之前先确保引入了spring-test 依赖（以Maven举例）

<dependency>

    <groupId>org.springframework</groupId>

    <artifactId>spring-test</artifactId>

    <version>version</version>

    <scope>test</scope>

</dependency>

通过获得File文件的名称、mime类型以及内容将其转换为MultipartFile格式。具体写法如下。

更多文章干货，推荐公众号【程序员老J】

最近博主看完了《SQL进阶教程》这本书，看完后给博主打开了SQL世界的新大门，对于 SQL 的理解不在局限于以前的常规用法。借用其他读者的评论，

读完醍醐灌顶，对SQL做到了知其然更能知其所以然。全书从头到尾强调了 SQL的内在逻辑是基于集合论和谓词逻辑，而这两条主线恰恰对使用SQL起到了至关重要的指导作用。

本文给大家总结如何让SQL起飞（优化）

一、SQL写法优化

在SQL中，很多时候不同的SQL代码能够得出相同结果。从理论上来说，我们认为得到相同结果的不同SQL之间应该有相同的性能，但遗憾的是，查询优化器生成的执行计划很大程度上受到SQL代码影响，有快有慢。因此如果想优化查询性能，我们必须知道如何写出更快的SQL，才能使优化器的执行效率更高。

1.1 子查询用EXISTS代替IN

当IN的参数是子查询时，数据库首先会执行子查询，然后将结果存储在一张临时的工作表里（内联视图），然后扫描整个视图。很多情况下这种做法都非常耗费资源。使用EXISTS的话，数据库不会生成临时的工作表。但是从代码的可读性上来看，IN要比EXISTS好。使用IN时的代码看起来更加一目了然，易于理解。因此，如果确信使用IN也能快速获取结果，就没有必要非得改成EXISTS了。

这里用Class_A表和Class_B举例，

我们试着从Class_A表中查出同时存在于Class_B表中的员工。下面两条SQL语句返回的结果是一样的，但是使用EXISTS的SQL语句更快一些。

--慢

SELECT *

  FROM Class_A

 WHERE id IN (SELECT id

                FROM Class_B);



--快

SELECT *

  FROM Class_A  A

 WHERE EXISTS

        (SELECT *

          FROM Class_B  B

          WHERE A.id = B.id);

使用EXISTS时更快的原因有以下两个。

实际上，大部分情况在子查询数量较小的场景下EXISTS和IN的查询性能不相上下，由EXISTS查询更快第二点可知，子查询数量较大时使用EXISTS才会有明显优势。

1.2 避免排序并添加索引

在SQL语言中，除了ORDER BY子句会进行显示排序外，还有很多操作默认也会在暗中进行排序，如果排序字段没有添加索引，会导致查询性能很慢。SQL中会进行排序的代表性的运算有下面这些。

• GR0UP BY子句


• ORDER BY子句


• 聚合函数（SUM、COUNT、AVG、MAX、MIN）


• DISTINCT


• 集合运算符（UNION、INTERSECT、EXCEPT）


• 窗口函数（RANK、ROW_NUMBER等）

如上列出的六种运算（除了集合运算符），它们后面跟随或者指定的字段都可以添加索引，这样可以加快排序。

实际上在DISTINCT关键字、GR0UP BY子句、ORDER BY子句、聚合函数跟随的字段都添加索引，不仅能加速查询，还能加速排序。

1.3 用EXISTS代替DISTINCT

为了排除重复数据，我们可能会使用DISTINCT关键字。如1.2中所说，默认情况下，它也会进行暗中排序。如果需要对两张表的连接结果进行去重，可以考虑使用EXISTS代替DISTINCT，以避免排序。这里用Items表和SalesHistory表举例：

我们思考一下如何从上面的商品表Items中找出同时存在于销售记录表SalesHistory中的商品。简而言之，就是找出有销售记录的商品。

在一（Items）对多（SalesHistory）的场景下，我们需要对item_no去重，使用DISTINCT去重，因此SQL如下：

SELECT DISTINCT I.item_no

  FROM Items I INNER JOIN SalesHistory SH

    ON I. item_no = SH. item_no;



item_no

-------

    10

    20

    30

使用EXISTS代替DISTINCT去重，SQL如下：

SELECT item_no

  FROM Items I

 WHERE EXISTS

          (SELECT ＊

              FROM SalesHistory SH

            WHERE I.item_no = SH.item_no);

item_no

-------

    10

    20

    30

这条语句在执行过程中不会进行排序。而且使用EXISTS和使用连接一样高效。

1.4 集合运算ALL可选项

SQL中有UNION、INTERSECT、EXCEPT三个集合运算符。在默认的使用方式下，这些运算符会为了排除掉重复数据而进行排序。

MySQL还没有实现INTERSECT和EXCEPT运算

如果不在乎结果中是否有重复数据，或者事先知道不会有重复数据，请使用UNION ALL代替UNION。这样就不会进行排序了。

1.5 WHERE条件不要写在HAVING字句

例如，这里继续用SalesHistory表举例，下面两条SQL语句返回的结果是一样的：

--聚合后使用HAVING子句过滤

SELECT sale_date, SUM(quantity)

  FROM SalesHistory

 GR0UP BY sale_date

HAVING sale_date = '2007-10-01';



--聚合前使用WHERE子句过滤

SELECT sale_date, SUM(quantity)

  FROM SalesHistory

 WHERE sale_date = '2007-10-01'

 GR0UP BY sale_date;

但是从性能上来看，第二条语句写法效率更高。原因有两个：

二、真的用到索引了吗

2.1 隐式的类型转换

如下，col_1字段是char类型：

-- 没走索引

SELECT * FROM SomeTable WHERE col_1 = 10;

-- 走了索引

SELECT * FROM SomeTable WHERE col_1 ='10';

-- 走了索引

SELECT * FROM SomeTable WHERE col_1 = CAST(10, AS CHAR(2));

当查询条件左边和右边类型不一致时会导致索引失效。

2.2 在索引字段上进行运算

如下：

SELECT *

  FROM SomeTable

 WHERE col_1 * 1.1 > 100;

在索引字段col_1上进行运算会导致索引不生效，把运算的表达式放到查询条件的右侧，就能用到索引了，像下面这样写就OK了。

WHERE col_1 > 100 / 1.1

如果无法避免在左侧进行运算，那么使用函数索引也是一种办法，但是不太推荐随意这么做。使用索引时，条件表达式的左侧应该是原始字段请牢记，这一点是在优化索引时首要关注的地方。

2.3 使用否定形式

下面这几种否定形式不能用到索引。

• <>


• !=


• NOT

这个是跟具体数据库的优化器有关，如果优化器觉得即使走了索引，还是需要扫描很多很多行的话，他可以选择直接不走索引。平时我们用!=、<>、not in的时候，要注意一下。

2.4 使用OR查询前后没有同时使用索引

例如下表：

CREATE TABLE test_tb ( 

	id int(11) NOT NULL AUTO_INCREMENT, 

	name varchar(55) NOT NULL

	PRIMARY KEY (id)

) 

ENGINE=InnoDB DEFAULT CHARSET=utf8;

使用OR条件进行查询

SELECT * 

FROM test_tb 

WHERE id = 1 OR name = 'tom'

这个SQL的执行条件下，很明显id字段查询会走索引，但是对于OR后面name字段的查询是需要进行全表扫描的。在这个场景下，优化器会选择直接进行一遍全表扫描。

2.5 使用联合索引时，列的顺序错误

使用联合索引需要满足最左匹配原则，即最左优先。如果你建立一个（col_1, col_2, col_3）的联合索引，相当于建立了 (col_1)、(col_1,col_2)、(col_1,col_2,col_3) 三个索引。如下例子：

-- 走了索引

SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 AND col_3 = 500;

-- 走了索引

SELECT * FROM SomeTable WHERE col_1 = 10 AND col_2 = 100 ;

-- 没走索引

SELECT * FROM SomeTable WHERE col_1 = 10 AND col_3 = 500 ;

-- 没走索引

SELECT * FROM SomeTable WHERE col_2 = 100 AND col_3 = 500 ;

-- 走了索引

SELECT * FROM SomeTable WHERE col_2 = 100 AND col_1 = 10 ;

联合索引中的第一列（col_1）必须写在查询条件的开头，而且索引中列的顺序不能颠倒。

可能需要说明的是最后一条SQL为什么会走索引，简单转化一下，col_2 = 100 AND col_1 = 10，
这个条件就相当于col_1 = 10 AND col_2 = 100，自然就可以走联合索引。

2.6 使用LIKE查询

并不是用了like通配符，索引一定会失效，而是like查询是以%开头，才会导致索引失效。

-- 没走索引

SELECT  *  FROM  SomeTable  WHERE  col_1  LIKE'%a';

-- 没走索引

SELECT  *  FROM  SomeTable  WHERE  col_1  LIKE'%a%';

-- 走了索引

SELECT  *  FROM  SomeTable  WHERE  col_1  LIKE'a%';

2.7 连接字段字符集编码不一致

如果两张表进行连接，关联字段编码不一致会导致关联字段上的索引失效，这是博主在线上经历一次SQL慢查询后的得到的结果，举例如下，有如下两表，它们的name字段都建有索引，但是编码不一致，user表的name字段编码是utf8mb4，user_job表的name字段编码是utf8，

CREATE TABLE `user` (

  `id` int NOT NULL AUTO_INCREMENT,

  `name` varchar(255) CHARACTER

  SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL,

  `age` int NOT NULL,

  PRIMARY KEY (`id`),

  KEY `idx_name` (`name`)

) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;



CREATE TABLE `user_job` (

  `id` int NOT NULL,

  `userId` int NOT NULL,

  `job` varchar(255) DEFAULT NULL,

  `name` varchar(255) DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `idx_name` (`name`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

进行SQL查询如下：

EXPLAIN

SELECT * 

from `user` u 

join user_job j on u.name = j.name

由结果可知，user表查询走了索引，user_job表的查询没有走索引。想要user_job表也走索引，可以把user表的name字段编码改成utf8即可。

三、减少中间表

在SQL中，子查询的结果会被看成一张新表，这张新表与原始表一样，可以通过代码进行操作。这种高度的相似性使得SQL编程具有非常强的灵活性，但是如果不加限制地大量使用中间表，会导致查询性能下降。

频繁使用中间表会带来两个问题，一是展开数据需要耗费内存资源，二是原始表中的索引不容易使用到（特别是聚合时）。因此，尽量减少中间表的使用也是提升性能的一个重要方法。

3.1 使用HAVING子句

对聚合结果指定筛选条件时，使用HAVING子句是基本原则。不习惯使用HAVING子句的人可能会倾向于像下面这样先生成一张中间表，然后在WHERE子句中指定筛选条件。例如下面：

SELECT * 

  FROM (

    SELECT sale_date, MAX(quantity) max_qty

      FROM SalesHistory

       GR0UP BY sale_date

     ) tmp

 WHERE max_qty >= 10

然而，对聚合结果指定筛选条件时不需要专门生成中间表，像下面这样使用HAVING子句就可以。

SELECT sale_date, MAX(quantity)

  FROM SalesHistory

 GR0UP BY sale_date

HAVING MAX(quantity) >= 10;

HAVING子句和聚合操作是同时执行的，所以比起生成中间表后再执行的WHERE子句，效率会更高一些，而且代码看起来也更简洁。

3.2 对多个字段使用IN

当我们需要对多个字段使用IN条件查询时，可以通过 || 操作将字段连接在一起变成一个字符串处理。

SELECT *

  FROM Addresses1 A1

 WHERE id || state || city

    IN (SELECT id || state|| city

          FROM Addresses2 A2);

这样一来，子查询不用考虑关联性，而且只执行一次就可以。

需要说明的MySql中，|| 操作符是代表或者也就是OR的意思。在Mysql中可以使用下面多种写法，如下：

-- 使用CONCAT(str1,str2,...)函数，将多列合并为一个字符串

SELECT *

  FROM Addresses1 A1

 WHERE CONCAT(id, state, city)

    IN ('1湖北武汉', '2湖北黄冈');



-- 使用多列in查询

SELECT *

  FROM Addresses1 A1

 WHERE (id, state, city)

    IN ((1, '湖北', '武汉'), (2, '湖北', '黄冈'));

使用多列in查询这个语法在实际执行中可以走索引，CONCAT(str1,str2,...) 函数不能。

3.3 先进行连接再进行聚合

连接和聚合同时使用时，先进行连接操作可以避免产生中间表。原因是，从集合运算的角度来看，连接做的是“乘法运算”。连接表双方是一对一、一对多的关系时，连接运算后数据的行数不会增加。而且，因为在很多设计中多对多的关系都可以分解成两个一对多的关系，因此这个技巧在大部分情况下都可以使用。

到此本文讲解完毕，感谢大家阅读，感兴趣的朋友可以点赞加关注，你的支持将是我更新动力😘。

一个警告

近期组里来了新同学，依赖注入的时候习惯使用@Autowired，发现被idea黄色警告，跑过来问大家。由于我平时习惯使用@Resource，没太注意过这个问题，刚好趁着这个机会学习了一波。

首先看下问题的现象，使用@Autowired被idea警告，而使用@Resource则不会：

@Autowired和@Resource的差异

来源

• @Resource是JSR 250中的内容，发布时间是2006年


• @Autowired是Spring2.5中的内容，发布时间是2007年

@Resource是JSR的标准，Spring框架也提供了实现。既然@Autowired是在@Resource之后发布的，应该就有@Resource不能表达的含义或者不能实现的功能。

用法

注入方式

虽然我们开发中使用最多的方式是属性注入，但其实存在构造函数注意、set方法注入等方式。相比于@Resource支持的属性注入和set方法注入，@Autowired还能支持构造方法注入的形式，@Resource是不行的。

可指定属性

@Autowired支持required属性

@Resource支持7个其它属性

bean查找策略

• @Autowired是类型优先，如果这个类型的bean有多个，再根据名称定位


• @Resource是名称优先，如果不存在这个名称的bean，再去根据类型查找

查找过程

@Autowired

@Resource

思考

对于大多数开发同学来说，@Autowired 和 @Resource 差异是很小的，虽然 @Autowired 多支持构造器注入的形式，但是直接属性注入真的太灵活太香了。而@Autowired晚生于@Resource，既然已经有JSR标准的@Resource，还要增加1个特有Autowired，必然有Spring的考虑。

个人认为，构造器注入和支持属性不同这个理由是很弱的，这些特性完全可以在@Resource上实现，也不违反JSR的约束。比较可能的原因是，含义的不同，而最大的不同体现在bean查找策略上，@Autowired默认byType，@Resource默认byName，这个不同其实隐含了，@Resource注入的bean，更加有确定性，你都已经确定了这个bean的名称了，而类型在Java中编译过程本身是个强依赖，其实这里相当于指定了类型和名称，注入的是一个非常确定的资源。而@Autowired是类型优先，根据类型去查找，相比于@Resource，确定性更弱，我知道这里要注入bean的类型，但是我不确定这个bean的名称，也隐含体现了java多态的思想。

总结

回到开篇的idea的警告，网上有很多人都赞同的一种说法是，@Resource是JSR规范，@Autowired是Spring提供，不推荐使用绑定了Spring的@Autowired，因为@Resource在更换了框架后，依然可以使用。我不太赞同这种说法，因为idea的错误提示很明确，Field injection is not recommended，不推荐使用属性注入的方式，那换成@Resource，我理解并没有解决这个问题，虽然idea确实不警告了，可能有点掩耳盗铃的意思。

比较推荐的做法是，使用构造方法注入，虽然很多时候会有点麻烦，特别是增加依赖的时候，但是正是这种麻烦，会让你不再那么随意做属性注入，更能保持类的职责单一。然后配合lombok，也可以让你省去这种麻烦，不过希望还是能通过这个警告时刻提醒自己保持类的职责单一。

最近程序员界又重新流行起来了防御性编程这个概念，早期嘞，这个概念代表是一种细致、谨慎的编程方法。

防御性编程的目的是为了开发可靠的软件，我们在设计系统中每个组件的时候，都需要使其尽可能的 "保护" 自己。

但是 2023 年以来，国内的互联网市场是什么行情，相信大家都清楚，整个市场环境都在强调降本增效、开猿节流。

因此为了体现程序员们在公司代码中的不可替代性？防止被裁。"防御性编程" 概念又重新流行了起来。

不过这次它可不再是保护程序了，而是保护广大程序员群体 😎。

所以我就给大家介绍一下，新时代背景下的 "防御性" 编程理念，如何实践 😜。

本文大纲如下，

代码书写

变量名称使用单一字符

Java 语言里变量名只能由 Unicode 字母、数字、下划线或美元符号组成，并且第一个字符不能是数字。

那么对于单一字符的变量名称来说，26 个字母大写加 26 个字母小写加下划线以及美元符一共有 54 种变量名称，想一想难道这些还不够你在单个 Java 文件里给变量命名用吗？

兄弟这一般够用了。

使用中文命名

兄弟，大家都是中国人，肯定看得懂中文咯。

就问你，Idea 支不支持吧，有没有提示说你变量名不规范嘛！没提示就是规范。

还有一点，兄弟们，还记得上面 Java 语言里变量名组成规范吗？中文也在 Unicode 编码里面，所以其实我们还可以用中文作为变量名称。

我已经帮你查好了，Java 里常用的 utf-8 编码下，支持的中文字符有 20902 个，所以上面单一字符的变量名称还需要新增 20902 种 😃，简直完美。

使用多国语言命名

不多说，我就问你看不看得懂吧，看得懂算你厉害，看不懂算你技术不行。

你问我看不看得懂，我当然看的懂，我写的，我请百度翻译的 😝。

这些变量名称命名法则，不仅适用与 Java，也适用于 JavaScript，广大前端程序员也有福了。

CV 大法

不要抽象、不要封装、不要继承、不要组合，我只会 CV。

抽象

抽象：我可以让调用者只需要关心方法提供了哪些功能，而不需要知道这些功能是如何实现的。我的好处是可以减少信息的复杂度，提高代码的可读性和易用性，也方便了代码的修改和扩展，我厉害吧。

我：我只会 CV。

抽象：...

封装

封装：我可以把数据和基于数据的操作封装在一起，使其构成一个独立的实体，对外只暴露有限的访问接口，保护内部的数据不被外部随意访问和修改。我的好处是可以增强数据的安全性和一致性，减少代码的耦合性，也提高了类的易用性。看见没，我比抽象好懂吧。

我：我只会 CV。

封装：...

继承

继承：我可以让一个类继承另一个类的属性和方法，从而实现代码的复用和扩展。我可以表示类之间的 is-a 关系，体现了类的层次结构和分类。我的好处是可以避免代码的重复，简化类的定义，也增加了代码的维护性。我可是面向对象三大特征之一。

我：我只会 CV。

继承：...

组合

组合：我可以让一个类包含另一个类的对象作为自己的属性，从而实现代码的复用和扩展。我可以表示类之间的 has-a 关系，体现了类的关联和聚合。我的好处是可以增加类的灵活性和可变性，也降低了类之间的耦合性。不要用继承，我可是比继承更优秀的。

我：我只会 CV。

组合：...

不要问为什么我只会 CV，因为我的键盘只有 CV。

刚出道时我们嘲讽 CV，后来逐渐理解 CV，最后我们成为 CV。

CV 的越多，代码就越复杂，代码越复杂，同事就越难看懂，同事越难看懂，就越难接手你的代码，你的不可替代性就越来越强。

那么我们防御性编程的目的不久达到了嘛。

兄弟，听我说，给你的代码上防御，是为了你好！

产品开发

运营配置、开发配置、系统配置直接写死，用魔法值，没毛病。

产品每次提需求，代码实现一定要做到最小细粒度实现，做到需求里少一个字，我的代码里绝不会多一个词，注释也是不可能有的，我写的代码只有我看得懂不是防御性编程的基操吗？

我的代码我做主。

产品原型不提，我绝对不会问。要做到这系统有你才能每一次发版上线都是相安无事，一旦缺少了你，鬼知道会发生什么。

我们能做的就是牢牢把握项目中核心成员的位置。这个项目组少了你，绝对不行！

最后聊两句

2023 全年都在降本增效，节能开猿的浪潮下度过。

虽然本文是给大家讲防御性编程如何实践，但终究只是博君一笑，请勿当真。

这里我还是希望每一个互联网打工人都能平稳度过这波寒冬。

积蓄力量，多思考，多元发展。

在来年，春暖花开，金三银四之月，都能找到自己满意的工作，得到属于自己的果实。

关注公众号【waynblog】，每周分享技术干货、开源项目、实战经验、高效开发工具等，您的关注将是我的更新动力😘。

1 场景还原

1.1 版本信息

MySQL版本：5.6.36-82.1-log 

Mybatis-Plus的starter版本：3.3.2

存储引擎：InnoDB

1.2 死锁现象

A同学在生产环境使用了Mybatis-Plus提供的 com.baomidou.mybatisplus.extension.service.IService#saveOrUpdate(T, com.baomidou.mybatisplus.core.conditions.Wrapper) 方法（以下简称B方法），并发场景下，数据库报了如下错误

2 为什么是间隙锁死锁？

如上图示，数据库报了死锁，那死锁场景千万种，为什么确定B方法是由于间隙锁导致的死锁？

2.1 什么是死锁？

两个事务互相等待对方持有的锁，导致互相阻塞，从而导致死锁。

2.2 什么是间隙锁？

• 间隙锁是MySQL行锁的一种，与Record lock不同的是间隙锁锁定的是一个间隙。


• 锁定规则如下：

MySQL会向左找第一个比当前索引值小的值，向右找第一个比当前索引值大 的值（没有则为正无穷），将此区间锁住，从而阻止其他事务在此区间插入数据。

2.3 MySQL为什么要引入间隙锁？

与Record lock组合成Next-key lock，在可重复读这种隔离级别下一起工作避免幻读。

2.4 间隙锁死锁分析

理论上一款开源的框架，经过了多年打磨，提供的方法不应该造成如此严重的错误，但理论仅仅是理论上，事实就是发生了死锁，于是我们开始了一轮深度排查。首先我们从这个方法的源码入手，源码如下：

    default boolean saveOrUpdate(T entity, Wrapper updateWrapper) {

        return this.update(entity, updateWrapper) || this.saveOrUpdate(entity);

    }

从源码上看此方法就没有按套路出牌，正常逻辑应该是首先执行查询，存在则修改，不存在则新增，但此方法上来就执行了修改。我们就猜想是不是MySQL在修改时增加了什么锁导致了死锁，于是我们找到了DBA获取了最新的死锁日志，即执行show engine innodb status，我们发现了两项关键信息如下：

*** (1) TRANSACTION:

...省略日志

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 0 page no 347 n bits 80 index `PRIMARY` of table `database_name`.`table_name` trx id 71C lock_mode X locks gap before rec insert intention waiting

  

*** (2) TRANSACTION:

...省略日志

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 0 page no 347 n bits 80 index `PRIMARY` of table `database_name`.`table_name` trx id 71D lock_mode X locks gap before rec insert intention waiting

简单翻译一下，就是事务一在获取插入意向锁时，需要等待间隙锁（事务二添加）释放，同时事务二在获取插入意向锁时，也在等待间隙锁释放（事务一添加）， （本文不讨论MySQL在修改与插入时添加的锁，我们把修改时添加间隙锁，插入时获取插入意向锁为已知条件） 那我们回到B方法，并发场景下，是不是就很大几率会满足事务一和事务二相互等待对方持有的间隙锁，从而导致死锁。

现在我们理论有了，我们现在用真实数据来验证此场景。

2.5 验证间隙锁死锁

• 准备如下表结构（以下简称验证一）

create table t_gap_lock(

id int auto_increment primary key comment '主键ID',

name varchar(64) not null comment '名称',

age int not null comment '年龄'

) comment '间隙锁测试表';

• 准备如下表数据

mysql> select * from t_gap_lock;

+----+------+-----+

| id | name | age |

+----+------+-----+

|  1 | 张三 |  18 |

|  5 | 李四 |  19 |

|  6 | 王五 |  20 |

|  9 | 赵六 |  21 |

| 12 | 孙七 |  22 |

+----+------+-----+

• 我们开启事务一，并执行如下语句，注意这个时候我们还没有提交事务

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 4;

Query OK, 0 rows affected (0.00 sec)

Rows matched: 0  Changed: 0  Warnings: 0

• 同时我们开启事务二，并执行如下语句，事务二我们同样不提交事务

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 7;

Query OK, 0 rows affected (0.00 sec)

Rows matched: 0  Changed: 0  Warnings: 0

• 接下来我们在事务一中执行如下语句

mysql> insert int0 t_gap_lock(id, name, age) value (7,'间隙锁7',27);  

• 我们会发现事务一被阻塞了，然后我们执行以下语句看下当前正在锁的事务。

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS \G;

*************************** 1. row ***************************

    lock_id: 749:0:360:3

lock_trx_id: 749

  lock_mode: X,GAP

  lock_type: RECORD

 lock_table: `test`.`t_gap_lock`

 lock_index: `PRIMARY`

 lock_space: 0

  lock_page: 360

   lock_rec: 3

  lock_data: 5

*************************** 2. row ***************************

    lock_id: 74A:0:360:3

lock_trx_id: 74A

  lock_mode: X,GAP

  lock_type: RECORD

 lock_table: `test`.`t_gap_lock`

 lock_index: `PRIMARY`

 lock_space: 0

  lock_page: 360

   lock_rec: 3

  lock_data: 5

2 rows in set (0.00 sec)

根据lock_type和lock_mode我们可以很清晰的看到锁类型是行锁，锁模式是间隙锁。

• 与此同时我们在事务二中执行如下语句

insert int0 t_gap_lock(id, name, age) value (4,'间隙锁4',24);

• 一执行以上语句，数据库就立马报了死锁，并且回滚了事务二（可以在死锁日志中看到*** WE ROLL BACK TRANSACTION (2)）

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction 

到这里，细心的同学就会发现，诶，你这上面故意造了一个间隙，并且让两个事务分别在对方的间隙中插入数据，太刻意了，生产环境基本上不会有这种场景，是的，生产环境怎么会有这种场景呢，上面的数据只是为了让大家直观的看到间隙锁的死锁过程，接下来那我们再来一组数据，我们简称验证二。

• 我们还是以验证一的表结构与数据，我们来执行这样一个操作。首先我们开始开启事务一并且执行如下操作，依然不提交事务

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 4;

Query OK, 0 rows affected (0.00 sec)

Rows matched: 0  Changed: 0  Warnings: 0 

• 同时我们开启事务二，执行与事务一一样的操作，我们会惊奇的发现，竟然也成功了。

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 4;

Query OK, 0 rows affected (0.00 sec)

Rows matched: 0  Changed: 0  Warnings: 0 

• 于是乎我们在事务一执行如下操作，我们又惊奇的发现事务一被阻塞了。

insert int0 t_gap_lock(id, name, age) value (4,'间隙锁4',24);  

• 在事务一被阻塞的同时，我们在事务二执行同样的语句，我们发现数据库立马就报了死锁。

insert int0 t_gap_lock(id, name, age) value (4,'间隙锁4',24);    

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

验证二完整的复现了线上死锁的过程，也就是事务一先执行了更新语句，事务二在同一时刻也执行了更新语句，然后事务一发现没有更新到就去执行主键查询语句，发现确实没有，所以执行了插入语句，但是插入要先获取插入意向锁，在获取插入意向锁的时候发现这个间隙已经被事务二加锁了，所以事务一开始等待事务二释放间隙锁，同理，事务二也执行上述操作，最终导致事务一与事务二互相等待对方释放间隙锁，最终导致死锁。

验证二还说明了一个问题，就是间隙锁加锁是非互斥的，也就是事务一对间隙A加锁后，事务二依然可以给间隙A加锁。

3 如何解决？

3.1 关闭间隙锁（不推荐）

• 降低隔离级别，例如降为提交读。


• 直接修改my.cnf，将开关，innodb_locks_unsafe_for_binlog改为1，默认为0即开启

PS：以上方法仅适用于当前业务场景确实不关心幻读的问题。

3.2 自定义saveOrUpdate方法（推荐）

建议自己编写一个saveOrUpdate方法，当然也可以直接采用Mybatis-Plus提供的saveOrUpdate方法，但是根据源码发现，会有很多额外的反射操作，并且还添加了事务，大家都知道，MySQL单表操作完全不需要开事务，会增加额外的开销。

  @Transactional(

        rollbackFor = {Exception.class}

    )

    public boolean saveOrUpdate(T entity) {

        if (null == entity) {

            return false;

        } else {

            Class cls = entity.getClass();

            TableInfo tableInfo = TableInfoHelper.getTableInfo(cls);

            Assert.notNull(tableInfo, "error: can not execute. because can not find cache of TableInfo for entity!", new Object[0]);

            String keyProperty = tableInfo.getKeyProperty();

            Assert.notEmpty(keyProperty, "error: can not execute. because can not find column for id from entity!", new Object[0]);

            Object idVal = ReflectionKit.getFieldValue(entity, tableInfo.getKeyProperty());

            return !StringUtils.checkValNull(idVal) && !Objects.isNull(this.getById((Serializable)idVal)) ? this.updateById(entity) : this.save(entity);

        }

    }

4 拓展

4.1 如果两个事务修改是存在的行会发生什么？

在验证二中两个事务修改的都是不存在的行，都能加间隙锁成功，那如果两个事务修改的是存在的行，MySQL还会加间隙锁吗？或者说把间隙锁从锁间隙降为锁一行？带着疑问，我们执行以下数据验证，我们还是使用验证一的表和数据。

• 首先我们开启事务一执行以下语句

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 1;

Query OK, 1 row affected (0.00 sec)

Rows matched: 1  Changed: 1  Warnings: 0

• 我们再开启事务二，执行同样的语句，发现事务二已经被阻塞

mysql> begin;

Query OK, 0 rows affected (0.00 sec)



mysql> update t_gap_lock t set t.age = 25 where t.id = 1;

• 这个时候我们执行以下语句看下当前正在锁的事务。

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS \G;

*************************** 1. row ***************************

    lock_id: 75C:0:360:2

lock_trx_id: 75C

  lock_mode: X

  lock_type: RECORD

 lock_table: `test`.`t_gap_lock`

 lock_index: `PRIMARY`

 lock_space: 0

  lock_page: 360

   lock_rec: 2

  lock_data: 1

*************************** 2. row ***************************

    lock_id: 75B:0:360:2

lock_trx_id: 75B

  lock_mode: X

  lock_type: RECORD

 lock_table: `test`.`t_gap_lock`

 lock_index: `PRIMARY`

 lock_space: 0

  lock_page: 360

   lock_rec: 2

  lock_data: 1

2 rows in set (0.00 sec)

根据lock_type和lock_mode我们看到事务一和二加的锁变成了Record Lock，并没有再添加间隙锁，根据以上数据验证MySQL在修改存在的数据时会给行加上Record Lock，与间隙锁不同的是该锁是互斥的，即不同的事务不能同时对同一行记录添加Record Lock。

5 结语

虽然Mybatis-Plus提供的这个方法可能会造成死锁，但是依然不可否认它是一款非常优秀的增强框架，其提供的lambda写法在日常工作中极大的提高了我们的开发效率，所以凡事都用两面性，我们应该秉承辩证的态度，熟悉的方法尝试用，陌生的方法谨慎用。

以上就是我们在生产环境间隙锁死锁分析的全过程，如果大家觉得本文让你对间隙锁，以及间隙锁死锁有一点的了解，别忘记一键三连，多多支持转转技术，转转技术在未来将会给大家带来更多的生产实践与探索。

背景

​

服务想必大家都有很多开发经验，但是从零开始搭建一个项目的经验，就少的多了。更不要说不使用任何框架的情况下从零开始搭建一个服务。那么这次就看看从零开始搭建一个好用好写web服务到底有多难？

HelloWorld

官网给出的helloworld例子。http标准库提供了两个方法，HandleFunc注册处理方法和ListenAndServe启动侦听接口。

假如业务更多

下面我们模拟一下接口增多的情况。可以看出有大量重复的部分。这样自然而然就产生了抽象服务的需求。

package main



import (

	"fmt"

	"net/http"

)



func greet(w http.ResponseWriter, r *http.Request) {

	fmt.Fprintf(w, "Greet!: %s\n", r.URL.Path)

}



func hello(w http.ResponseWriter, r *http.Request) {

	fmt.Fprintf(w, "Hello!: %s\n", r.URL.Path)

}



func notfound(w http.ResponseWriter, r *http.Request) {

	fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)

}



func main() {

	http.HandleFunc("/", notfound)

	http.HandleFunc("/hello", hello)

	http.HandleFunc("/greet", greet)

	http.ListenAndServe(":80", nil)

}

我们想要一个服务，它代表的是对某个端口监听的实例，它可以根据访问的路径，调用对应的方法。在需要的时候，我可以生成多个服务实例，监听多个端口。那么我们的Server需要实现下面两个方法。

type Server interface {

	Route(pattern string, handlerFunc http.HandlerFunc)



	Start(address string) error

}

简单实现一下。

package server



import "net/http"



type Server interface {

	Route(pattern string, handlerFunc http.HandlerFunc)

	Start(address string) error

}



type httpServer struct {

	Name string

}



func (s *httpServer) Route(pattern string, handlerFunc http.HandlerFunc) {

	http.HandleFunc(pattern, handlerFunc)

}



func (s *httpServer) Start(address string) error {

	return http.ListenAndServe(address, nil)

}



func NewHttpServer(name string) Server {

	return &httpServer{

		Name: name,

	}

}

修改业务代码

func main() {

	server := server.NewHttpServer("demo")

	server.Route("/", notfound)

	server.Route("/hello", hello)

	server.Route("/greet", greet)

	server.Start(":80")

}

格式化输入输出

在我们实际使用过程中，输入输出一般都是以json的格式。自然也需要通用的处理过程。

type Context struct {

	W http.ResponseWriter

	R *http.Request

}



func (c *Context) ReadJson(data interface{}) error {

	body, err := io.ReadAll(c.R.Body)

	if err != nil {

		return err

	}

	err = json.Unmarshal(body, data)

	if err != nil {

		return err

	}

	return nil

}



func (c *Context) WriteJson(code int, resp interface{}) error {

	c.W.WriteHeader(code)

	respJson, err := json.Marshal(resp)

	if err != nil {

		return err

	}

	_, err = c.W.Write(respJson)

	return err

}

模拟了一个常见的业务代码。定义了入参和出参。

type helloReq struct {

	Name string

	Age  string

}



type helloResp struct {

	Data string

}



func hello(w http.ResponseWriter, r *http.Request) {

	req := &helloReq{}

	ctx := &server.Context{

		W: w,

		R: r,

	}



	err := ctx.ReadJson(req)



	if err != nil {

		fmt.Fprintf(w, "err:%v", err)

		return

	}



	resp := &helloResp{

		Data: req.Name + "_" + req.Age,

	}



	err = ctx.WriteJson(http.StatusOK, resp)

	if err != nil {

		fmt.Fprintf(w, "err:%v", err)

		return

	}



}

用postman试一下，是不是和我们平常开发的接口有一点像了。

由于200，404，500的返回结果实在是太普遍了，我们当然也可以进一步封装输出方法。但是我觉得没必要。

在我们设计的过程中，是否要提供辅助性的方法，还是只聚焦核心功能，是非常值得考虑的问题。

func (c *Context) SuccessJson(resp interface{}) error {

	return c.WriteJson(http.StatusOK, resp)

}



func (c *Context) NotFoundJson(resp interface{}) error {

	return c.WriteJson(http.StatusNotFound, resp)

}



func (c *Context) ServerErrorJson(resp interface{}) error {

	return c.WriteJson(http.StatusInternalServerError, resp)

}

让框架来创建Context

观察下业务代码，还有个非常让人不舒服的地方。Context是框架内部使用的数据结构，居然要业务来创建！真的是太不合理了。

那么下面我们把Context移入框架内部创建，同时业务侧提供的handlefunction入参应该直接是由框架创建的Context。

首先修改我们的路由注册接口的定义。在实现中，我们注册了一个匿名函数，在其中构建了ctx的实例，并调用入参中业务的handlerFunc。

type Server interface {

	Route(pattern string, handlerFunc func(ctx *Context))

	Start(address string) error

}



func (s *httpServer) Route(pattern string, handlerFunc func(ctx *Context)) {

	http.HandleFunc(pattern, func(w http.ResponseWriter, r *http.Request) {

		ctx := NewContext(w, r)

		handlerFunc(ctx)

	})

}



func NewContext(w http.ResponseWriter, r *http.Request) *Context {

	return &Context{

		W: w,

		R: r,

	}

}

这样修改之后我们的业务代码也显得更干净了。

func hello(ctx *server.Context) {

	req := &helloReq{}

	err := ctx.ReadJson(req)



	if err != nil {

		ctx.ServerErrorJson(err)

		return

	}



	resp := &helloResp{

		Data: req.Name + "_" + req.Age,

	}



	err = ctx.WriteJson(http.StatusOK, resp)

	if err != nil {

		ctx.ServerErrorJson(err)

		return

	}

}

RestFul API 实现

当然我们现在发现，不管用什么方法调用我们的接口，都可以正常返回。但是我们平常都习惯写restful风格的接口。

那么在注册路由时，自然需要加上一个method的参数。注册时候也加上一个GET的声明。

type Server interface {

	Route(method string, pattern string, handlerFunc func(ctx *Context))

	Start(address string) error

}

server.Route(http.MethodGet, "/hello", hello)

那么我们自然可以这样写，当请求方法不等于我们注册方法时，返回error。

func (s *httpServer) Route(method string, pattern string, handlerFunc func(ctx *Context)) {

	http.HandleFunc(pattern, func(w http.ResponseWriter, r *http.Request) {

		if r.Method != method {

			w.Write([]byte("error"))

			return

		}

		ctx := NewContext(w, r)

		handlerFunc(ctx)

	})

}

那么我们现在就有了一个非常简单的可以实现restful api的服务了。

但是距离一个好用好写的web服务还有很大的进步空间。

背景

阿里java开发规范是阿里巴巴总结多年来的最佳编程实践，其中每一条规范都经过仔细打磨或踩坑而来，目的是为社区提供一份最佳编程规范，提升代码质量，减少bug。

这基本也是java业界都认可的开发规范，我们团队也是以此规范为基础，在结合实际情况，补充完善。最近在团队遇到的几个问题，加深了我对这份开发规范中几个点的理解，下面就一一道来。

日志规约

这条规范说明了，在异常发送记录日志时，要记录案发现场信息和异常堆栈信息，不处理要往上throws，切勿吃掉异常。

堆栈信息比较好理解，就是把整个方法调用链打印出来，方便定位具体是哪个方法出错。而案发现场信息我认为至少要能说明：“谁发生了什么错误”。

例如，哪个uid下单报错了，哪个订单支付失败了，原因是什么。否则满屏打印：“user error”，看到你都无从下手。

在我们这次出现的问题就是有一个feign，调用外部接口报错了，降级打印了不规范日志，导致排查问题花了很多时间。伪代码如下：

	@Slf4j

	@Component

	class MyClientFallbackFactory implements FallbackFactory<MyClient> {		



		@Override

		public MyClient create(Throwable cause) {

			return new MyClient() {

				@Override

				public Result<DataInfoVo> findDataInfo(Long id) {

					log.error("findDataInfo error");

					return Result.error(SYS_ERROR);

				}

			};

		}

	}

发版后错误日志开始告警，打开kibana看到了满屏了：“findDataInfo error”，然后开始一顿盲查。

因为这个接口本次并没有修改，所以猜测是目标服务出问题，上服务器curl接口，发现调用是正常的。

接着猜测是不是熔断器有问题，熔断后没有恢复，但重启服务后，还是继续报错。开始各种排查，arthas跟踪，最后实在没办法了，还是老老实实把异常打印出来，走发版流程。

log.error("{} findDataInfo error", id, cause);

有了异常堆栈信息就很清晰了，原来是返回参数反序列失败了，接口提供方新增一个不兼容的参数导致反序列失败。(这点在下一个规范还会提到)

可见日志打印不清晰给排查问题带来多大的麻烦，记住：日志一定要打印关键信息，异常要打印堆栈。

二方库依赖

上面提到的返回参数反序列化失败就是枚举造成的，原因是这个接口返回新增一个枚举值，这个枚举值原本返回给前端使用的，没想到还有其它服务也调用了它，最终在反序列化时就报错了，找不到“xxx”枚举值。

比如如下接口，你提交一个不认得的黑色BLACK，就会报反序列错误：

	enum Color {

		GREEN, RED

	}



	@Data

	class Test {

		private Color color;

	}



	@PostMapping(value = "/post/info")

	public void info(@NotNull Test test) {



	}



	curl --location 'localhost/post/info' \

	--header 'Content-Type: application/json' \

	--data '{

    	"testEnum": "BLACK"

	}'

关于这一点我们看下作者孤尽对它的阐述：

这就是我们出问题的场景，提供方新增了一个枚举值，而使用方没有升级，导致错误。可能有的同学说那通知使用方升级不就可以了？是的，但这出现了依赖问题，如果使用方有成百上千个，你会非常头痛。

那又为什么说不要使用枚举作为返回值，而可以作为输入参数呢？

我的理解是：作为枚举的提供者，不得随意新增/修改内容，或者说修改前要同步到所有枚举使用者，让大家知道，否则使用者就可能因为不认识这个枚举而报错，这是不可接受的。

但反过来，枚举提供者是可以将它作为输入参数的，如果调用者传了一个不存在的值就会报错，这是合理的，因为提供者并没有说支持这个值，调用者正常就不应该传递这个值，所以这种报错是合理的。

ORM映射

以下是规范里的说明：

1）增加查询分析器解析成本。

2）增减字段容易与 resultMap 配置不一致。

3）无用字段增加网络消耗，尤其是 text 类型的字段。

这都很好理解，就不过多说明。

在我们开发中，有的同学为了方便，还是使用了select *，一直以来也风平浪静，运行得好好的，直到有一天对该表加了个字段，代码没更新，报错了~，你没看错，代码没动，加个字段程序就报错了。

报错信息如下：

数组越界！问题可以在本地稳定复现，先把程序跑起来，执行 select * 的sql，再add column给表新增一个字段，再次执行相同的sql，报错。

具体原因是我们程序使用了sharding-jdbc做分表(5.1.2版本)，它会在服务启动时，加载字段信息缓存，在查询后做字段匹配，出错就在匹配时。

具体代码位置在：com.mysql.cj.protocol.a.MergingColumnDefinitionFactory#createFromFields

这个缓存是跟数据库链接相关的，只有链接失效时，才会重新加载。主要有两个参数和它相关：

spring.shardingsphere.datasource.master.idle-timeout 默认10min

spring.shardingsphere.datasource.master.max-lifetime 默认30min

默认缓存时间都比较长，你只能赶紧重启服务解决，而如果服务数量非常多，又是一个生产事故。

我在sharding sphere github搜了一圈，没有好的处理方案，相关链接如：

github.com/apache/shar…

github.com/apache/shar…

大体意思是如果真想这么做，数据库ddl需要通过sharding proxy，它会负责刷新客户端的缓存，但我们使用的是sharding jdbc模式，那只能老老实实遵循规范，不要select * 了。如果select具体字段，那新增的字段也不会被select出来，和缓存的就能对应上。

那么以后面试除了上面规范说到的，把这一点亲身经历也摆出来，应该可以加分吧。

总结

每条开发规范都有其背后的含义，都是经验总结和踩坑教训，对于团队的开发规范我们都要仔细阅读，严格遵守。可以看到上面每个小问题都可能导致不小的生产事故，保持敬畏之心，大概就是这个意思了吧。

更多分享，欢迎关注我的github：github.com/jmilktea/jt…

写在前面的话

灰度这个概念，来自数字图像领域，最初是描述黑白数字图像的灰度值，范围从 0 到 255，0 表示黑色，255 表示白色，中间的数值表示不同程度的灰色。

灰度系统的诞生源于交叉学科的建设，在互联网上也不例外。对于一个软件产品，在开发和发布的时候肯定希望用户能够顺利的看到想让其看到的内容。但是，发布没有一帆风顺的，如果在发布的某个环节出了问题，比如打错了镜像或者由于部署环境不同触发了隐藏的bug，导致用户看到了错误的页面或者旧的页面，这就出现了生产事故。为了避免这种情况出现，借鉴数字图像处理的理念，设计师们设计出了一种介于 0 和 1 之间的过渡系统的概念：让系统可以预先发布，并设置可见范围，就像朋友圈一样，等到风险可控后，再对公众可见。这就是灰度系统。

灰度系统版本的发布动作称作 灰度发布，又名金丝雀发布，或者灰度测试，他是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。(概念来自知乎)

对于前端领域，演进到现在，灰度系统主要有如下几点功能：

1. 增量灰度：小的patch可以增量的添加在发布版本上，也可以通过开关一键关闭
2. 用户灰度：增量和全量版本都可对不同群体或者某几个特定的用户进行灰度可见
3. 版本回退：每一个版本都在灰度系统里可见，可以一键回退

前端灰度系统工作流程图如下：

sequenceDiagram

前端项目-->灰度系统: 部署阶段

前端项目->>灰度系统: 1.CI 打包后写入打包资源，状态初始化

前端项目-->灰度系统: 访问阶段

前端项目->>灰度系统: 1.页面访问，请求当前登录用户对应的资源版本

灰度系统-->>前端项目: 2.从对应版本的资源目录返回前端资源

---

灰度规则

关于灰度资源优先级的说明如下：

灰度策略	优先级
未生效	低
生效	高
全量	一般

如此就起到了灰度的作用：全量表示所有人都可以看；生效表示只有在规则中的用户才可以看到这部分增量更新，优先级最高；未生效表示不灰度，优先级最低。

灰度系统数据库设计

为什么灰度系统有后端：前端项目 CI 部署后，会产生一个 commit 号和一个镜像记录，并且打包后的文件存放在服务器中某一个深层的文件夹目录中，灰度系统需要存入该部署的目录地址，便于在切换灰度时查找不同版本的文件。

先介绍一个要部署的前端项目（你可以根据自己的前端项目动态调整）。

本项目针对的前端项目是一个基于微服务架构的项目，

下面是设计ER图：

我们依此来分析：

子项目表

该表用于存放所有子项目的信息，新建一个微服务子项目时，会在这个表里新建一个条目，数据示意如下：

灰度用户表

用于灰度系统登录的用户，拥有灰度权限的人才可以加入。

资源表

资源表存放项目在 CI 中写入的 commit 信息和 build 完以后在服务器的存放位置，数据示意如下：

其中 branch 是跑CI的分支，data 存放打包资源目录信息，一般结构如下：

gitProjectId 存放该产品在 gitlab 中的项目号， status 表示构建状态：0：构建完成 1：部署完成 2：构建失败，3：部署失败。

这里简单提一下 CI 是如何写入灰度系统数据库的，过多详情不做解释，写入数据库方式很多，这只是其中一种实现方式。

1. 首先在 CI build 环节往服务器写入打包信息的 JSON：

其中 build.sh 负责把传入的参数写到一个 json 中。上图中是往根目录copy，方便下一个 CI job读取json文件的示意图。

2. 在 CI 部署环节，通过调用脚本创建资源：

其中 run_gray.js:

const { ENV, file, branch, projectId, gitProjectId, user, commitMsg } = require('yargs').argv;



axios({

    url: URL,

    method: "POST",

    headers: {

        remoteUser: user

    },

    data: {

        Action: "CreateResource",

        projectId,

        branch,

        commitMsg,

        gitProjectId,

        channel: Channel,

        data: fs.readFileSync(file, 'utf8'),

        status: "0"

    }

}).then(...)

其中 status 的变化，在 CI 部署服务器完成后，追加一个 UpdateResource 动作即可：

if [[ $RetCode != 0 ]]; then curl "$STARK_URL" -X 'POST' -H 'remoteUser: '"$GITLAB_USER_NAME"'' -H 'Content-Type: application/json' -d '{"Action": "UpdateResource", "id": "'"$ResourceId"'", "status": "2"}' > test.log && echo `cat test.log`; fi