在日常开发中，会经常使用Mybatis-Plus

当简单的插入一条记录时，使用mapper的insert是比较简洁的写法

@Data

public class NoEo {

    Long id;

    String no;

}

NoEo noEo = new NoEo();

noEo.setNo("321");

noMapper.insert(noEo);

System.out.println(noEo);

这里可以注意到一个细节，就是不管我们使用的是什么类型的id，好像都不需要去setId，也能执行insert语句

不仅不需要setId，在insert语句执行完毕之后，我们还能通过实体类获取到这条insert的记录的id是什么

这背后的原理是什么呢？

自增类型ID

刚学Java的时候，插入了一条记录还要再select一次来获取这条记录的id，比较青涩

后面误打误撞才发现可以直接从insert的实体类中拿到这个id

难道框架是自己帮我查了一次嘛

先来看看自增id的情况

首先要先把yml中的mp的id类型设置为auto

mybatis-plus:

  global-config:

    db-config:

      id-type: auto

然后从insert语句开始一直往下跟进

noMapper.insert(noEo);

后面会来到这个方法

// com.baomidou.mybatisplus.core.executor.MybatisSimpleExecutor#doUpdate

@Override

public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {

    Statement stmt = null;

    try {

        Configuration configuration = ms.getConfiguration();

        StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);

        stmt = prepareStatement(handler, ms.getStatementLog(), false);

        return stmt == null ? 0 : handler.update(stmt);

    } finally {

        closeStatement(stmt);

    }

}

在执行了下面这个方法之后

handler.update(stmt)

实体类的id就赋值上了

继续往下跟

// org.apache.ibatis.executor.statement.PreparedStatementHandler#update

@Override

public int update(Statement statement) throws SQLException {

  PreparedStatement ps = (PreparedStatement) statement;

  ps.execute();

  int rows = ps.getUpdateCount();

  Object parameterObject = boundSql.getParameterObject();

  KeyGenerator keyGenerator = mappedStatement.getKeyGenerator();

  keyGenerator.processAfter(executor, mappedStatement, ps, parameterObject);

  return rows;

}

最后的赋值在这一行

keyGenerator.processAfter

可以看到会有一个KeyGenerator做一个后置增强，它具体的实现类是Jdbc3KeyGenerator

// org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator#processAfter

@Override

public void processAfter(Executor executor, MappedStatement ms, Statement stmt, Object parameter) {

  processBatch(ms, stmt, parameter);

}

// org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator#processBatch

public void processBatch(MappedStatement ms, Statement stmt, Object parameter) {

  final String[] keyProperties = ms.getKeyProperties();

  if (keyProperties == null || keyProperties.length == 0) {

    return;

  }

  try (ResultSet rs = stmt.getGeneratedKeys()) {

    final ResultSetMetaData rsmd = rs.getMetaData();

    final Configuration configuration = ms.getConfiguration();

    if (rsmd.getColumnCount() < keyProperties.length) {

      // Error?

    } else {

      assignKeys(configuration, rs, rsmd, keyProperties, parameter);

    }

  } catch (Exception e) {

    throw new ExecutorException("Error getting generated key or setting result to parameter object. Cause: " + e, e);

  }

}

// org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator#assignKeys

private void assignKeys(Configuration configuration, ResultSet rs, ResultSetMetaData rsmd, String[] keyProperties,

    Object parameter) throws SQLException {

  if (parameter instanceof ParamMap || parameter instanceof StrictMap) {

    // Multi-param or single param with @Param

    assignKeysToParamMap(configuration, rs, rsmd, keyProperties, (Map<String, ?>) parameter);

  } else if (parameter instanceof ArrayList && !((ArrayList<?>) parameter).isEmpty()

      && ((ArrayList<?>) parameter).get(0) instanceof ParamMap) {

    // Multi-param or single param with @Param in batch operation

    assignKeysToParamMapList(configuration, rs, rsmd, keyProperties, (ArrayList<ParamMap<?>>) parameter);

  } else {

    // Single param without @Param

    // 当前case会走这里

    assignKeysToParam(configuration, rs, rsmd, keyProperties, parameter);

  }

}

// org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator#assignKeysToParam

private void assignKeysToParam(Configuration configuration, ResultSet rs, ResultSetMetaData rsmd,

    String[] keyProperties, Object parameter) throws SQLException {

  Collection<?> params = collectionize(parameter);

  if (params.isEmpty()) {

    return;

  }

  List<KeyAssigner> assignerList = new ArrayList<>();

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

    assignerList.add(new KeyAssigner(configuration, rsmd, i + 1, null, keyProperties[i]));

  }

  Iterator<?> iterator = params.iterator();

  while (rs.next()) {

    if (!iterator.hasNext()) {

      throw new ExecutorException(String.format(MSG_TOO_MANY_KEYS, params.size()));

    }

    Object param = iterator.next();

    assignerList.forEach(x -> x.assign(rs, param));

  }

}

// org.apache.ibatis.executor.keygen.Jdbc3KeyGenerator.KeyAssigner#assign

protected void assign(ResultSet rs, Object param) {

  if (paramName != null) {

    // If paramName is set, param is ParamMap

    param = ((ParamMap<?>) param).get(paramName);

  }

  MetaObject metaParam = configuration.newMetaObject(param);

  try {

    if (typeHandler == null) {

      if (metaParam.hasSetter(propertyName)) {

        // 获取主键的类型

        Class<?> propertyType = metaParam.getSetterType(propertyName);

        // 获取主键类型处理器

        typeHandler = typeHandlerRegistry.getTypeHandler(propertyType,

            JdbcType.forCode(rsmd.getColumnType(columnPosition)));

      } else {

        throw new ExecutorException("No setter found for the keyProperty '" + propertyName + "' in '"

            + metaParam.getOriginalObject().getClass().getName() + "'.");

      }

    }

    if (typeHandler == null) {

      // Error?

    } else {

      // 获取主键的值

      Object value = typeHandler.getResult(rs, columnPosition);

      // 设置主键值

      metaParam.setValue(propertyName, value);

    }

  } catch (SQLException e) {

    throw new ExecutorException("Error getting generated key or setting result to parameter object. Cause: " + e,

        e);

  }

}

// com.mysql.cj.jdbc.result.ResultSetImpl#getObject(int, java.lang.Class<T>)

@Override

public <T> T getObject(int columnIndex, Class<T> type) throws SQLException {

        // ...

        else if (type.equals(Long.class) || type.equals(Long.TYPE)) {

            checkRowPos();

            checkColumnBounds(columnIndex);

            return (T) this.thisRow.getValue(columnIndex - 1, this.longValueFactory);



        }

        // ...

}

最后可以看到这个自增id是在ResultSet的thisRow里面

然后后面的流程就是去解析这个字节数据获取这个long的id

就不往下赘述了

雪花算法ID

yml切换回雪花算法

mybatis-plus:

  global-config:

    db-config:

      id-type: assign_id

在使用雪花算法的时候，也是会走到这个方法

// com.baomidou.mybatisplus.core.executor.MybatisSimpleExecutor#doUpdate

@Override

public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {

    Statement stmt = null;

    try {

        Configuration configuration = ms.getConfiguration();

        StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);

        stmt = prepareStatement(handler, ms.getStatementLog(), false);

        return stmt == null ? 0 : handler.update(stmt);

    } finally {

        closeStatement(stmt);

    }

}

但是不同的是，执行完这一行之后，实体类的id字段就已经赋值上了

StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);

继续往下跟进

// org.apache.ibatis.session.Configuration#newStatementHandler

public StatementHandler newStatementHandler(Executor executor, MappedStatement mappedStatement, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {

  StatementHandler statementHandler = new RoutingStatementHandler(executor, mappedStatement, parameterObject, rowBounds, resultHandler, boundSql);

  statementHandler = (StatementHandler) interceptorChain.pluginAll(statementHandler);

  return statementHandler;

}

// org.apache.ibatis.executor.statement.RoutingStatementHandler#RoutingStatementHandler

public RoutingStatementHandler(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) {



  switch (ms.getStatementType()) {

    // ...

    case PREPARED:

      delegate = new PreparedStatementHandler(executor, ms, parameter, rowBounds, resultHandler, boundSql);

      break;

    // ...

  }



}

最后跟进到一个构造器，会有一个processParameter的方法

// com.baomidou.mybatisplus.core.MybatisParameterHandler#MybatisParameterHandler

public MybatisParameterHandler(MappedStatement mappedStatement, Object parameter, BoundSql boundSql) {

    this.typeHandlerRegistry = mappedStatement.getConfiguration().getTypeHandlerRegistry();

    this.mappedStatement = mappedStatement;

    this.boundSql = boundSql;

    this.configuration = mappedStatement.getConfiguration();

    this.sqlCommandType = mappedStatement.getSqlCommandType();

    this.parameterObject = processParameter(parameter);

}

在这个方法里面会去增强参数

// com.baomidou.mybatisplus.core.MybatisParameterHandler#processParameter

public Object processParameter(Object parameter) {

    /* 只处理插入或更新操作 */

    if (parameter != null

        && (SqlCommandType.INSERT == this.sqlCommandType || SqlCommandType.UPDATE == this.sqlCommandType)) {

        //检查 parameterObject

        if (ReflectionKit.isPrimitiveOrWrapper(parameter.getClass())

            || parameter.getClass() == String.class) {

            return parameter;

        }

        Collection<Object> parameters = getParameters(parameter);

        if (null != parameters) {

            parameters.forEach(this::process);

        } else {

            process(parameter);

        }

    }

    return parameter;

}

// com.baomidou.mybatisplus.core.MybatisParameterHandler#process

private void process(Object parameter) {

    if (parameter != null) {

        TableInfo tableInfo = null;

        Object entity = parameter;

        if (parameter instanceof Map) {

            Map<?, ?> map = (Map<?, ?>) parameter;

            if (map.containsKey(Constants.ENTITY)) {

                Object et = map.get(Constants.ENTITY);

                if (et != null) {

                    entity = et;

                    tableInfo = TableInfoHelper.getTableInfo(entity.getClass());

                }

            }

        } else {

            tableInfo = TableInfoHelper.getTableInfo(parameter.getClass());

        }

        if (tableInfo != null) {

            //到这里就应该转换到实体参数对象了,因为填充和ID处理都是争对实体对象处理的,不用传递原参数对象下去.

            MetaObject metaObject = this.configuration.newMetaObject(entity);

            if (SqlCommandType.INSERT == this.sqlCommandType) {

                populateKeys(tableInfo, metaObject, entity);

                insertFill(metaObject, tableInfo);

            } else {

                updateFill(metaObject, tableInfo);

            }

        }

    }

}

最终生成id并赋值的操作是在populateKeys中

// com.baomidou.mybatisplus.core.MybatisParameterHandler#populateKeys

protected void populateKeys(TableInfo tableInfo, MetaObject metaObject, Object entity) {

    final IdType idType = tableInfo.getIdType();

    final String keyProperty = tableInfo.getKeyProperty();

    if (StringUtils.isNotBlank(keyProperty) && null != idType && idType.getKey() >= 3) {

        final IdentifierGenerator identifierGenerator = GlobalConfigUtils.getGlobalConfig(this.configuration).getIdentifierGenerator();

        Object idValue = metaObject.getValue(keyProperty);

        if (StringUtils.checkValNull(idValue)) {

            if (idType.getKey() == IdType.ASSIGN_ID.getKey()) {

                if (Number.class.isAssignableFrom(tableInfo.getKeyType())) {

                    metaObject.setValue(keyProperty, identifierGenerator.nextId(entity));

                } else {

                    metaObject.setValue(keyProperty, identifierGenerator.nextId(entity).toString());

                }

            } else if (idType.getKey() == IdType.ASSIGN_UUID.getKey()) {

                metaObject.setValue(keyProperty, identifierGenerator.nextUUID(entity));

            }

        }

    }

}

在tableInfo中可以得知Id的类型

如果是雪花算法类型，那么生成雪花id；UUID同理

总结

insert之后，id被赋值到实体类的时机要根据具体情况具体讨论：

如果是自增类型的id，那么要在插入数据库完成之后，在ResultSet的ByteArrayRow中获取到这个id

如果是雪花算法id，那么在在插入数据库之前，会通过参数增强的方式，提前生成一个雪花id，然后赋值给实体类

MyBatis-Plus是一个功能强大的MyBatis扩展插件，它提供了许多便捷的注解，让我们在开发过程中能够更加高效地完成数据库操作，本文将带你一一了解这些注解，并通过实例来展示它们的魅力。

一、@Tablename注解

这个注解用于指定实体类对应的数据库表名。如果你的表名和实体类名不一致，就需要用到它：

@TableName("user_info")

public class UserInfo {

    // 类的属性和方法

}

在上述代码中，即使实体类名为UserInfo，但通过@TableName注解，我们知道它对应数据库中的"user_info"表。

二、@Tableld注解

每个数据库表都有主键，@TableId注解用于标识实体类中的主键属性。通常与@TableName配合使用，确保主键映射正确。

AUTO(0),

NONE(1),

INPUT(2),

ASSIGN_ID(3),

ASSIGN_UUID(4),

/** @deprecated */

@Deprecated

ID_WORKER(3),

/** @deprecated */

@Deprecated

ID_WORKER_STR(3),

/** @deprecated */

@Deprecated

UUID(4);

• INPUT 如果开发者没有手动赋值，则数据库通过自增的方式给主键赋值，如果开发者手动赋值，则存入该值。


• AUTO 默认就是数据库自增，开发者无需赋值。


• ASSIGN_ID MP 自动赋值，雪花算法。


• ASSIGN_UUID 主键的数据类型必须是 String，自动生成 UUID 进行赋值。

// 自己赋值

    //@TableId(type = IdType.INPUT)

    // 默认使用的雪花算法，长度比较长，所以使用Long类型，不用自己赋值

    @TableId

    private Long id;

测试

@Test

    void save(){

        // 由于id加的有注解，这里就不用赋值了

        Student student = new Student();

        student.setName("天明");

        student.setAge(18);

        mapper.insert(student);

}

雪花算法

雪花算法是由Twitter公布的分布式主键生成算法，它能够保证不同表的主键的不重复性，以及相同表的主键的有序性。

核心思想：

• 长度共64bit（一个long型）。


• 首先是一个符号位，1bit标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0。


• 41bit时间截(毫秒级)，存储的是时间截的差值（当前时间截 - 开始时间截)，结果约等于69.73年。


• 10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID，可以部署在1024个节点）。


• 12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID）。

优点：  整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞，并且效率较高。

三、@TableField注解

当你的实体类属性名与数据库字段名不一致时，@TableField注解可以帮助你建立二者之间的映射关系。

• 映射非主键字段，value 映射字段名；


• exist 表示是否为数据库字段 false，如果实体类中的成员变量在数据库中没有对应的字段，则可以使用 exist，VO、DTO；


• select 表示是否查询该字段；


• fill 表示是否自动填充，将对象存入数据库的时候，由 MyBatis Plus 自动给某些字段赋值，create_time、update_time。

自动填充

1）给表添加 create_time、update_time 字段。

2）实体类中添加成员变量。

package com.md.entity;



import com.baomidou.mybatisplus.annotation.*;

import com.md.enums.StatusEnum;

import lombok.Data;

import java.util.Date;



@Data

@TableName(value = "student")

public class Student {

    @TableId

    private Long id;



    // 当该字段名称与数据库名字不一致

    @TableField(value = "name")

    private String name;



    // 不查询该字段

    @TableField(select = false)

    private Integer age;



    // 当数据库中没有该字段，就忽略

    @TableField(exist = false)

    private String gender;



    // 第一次添加填充

    @TableField(fill = FieldFill.INSERT)

    private Date createTime;



    // 第一次添加的时候填充，但之后每次更新也会进行填充

    @TableField(fill = FieldFill.INSERT_UPDATE)

    private Date updateTime;



}

3）创建自动填充处理器。

注意：不要忘记添加 @Component 注解。

package com.md.handler;



import com.baomidou.mybatisplus.core.handlers.MetaObjectHandler;

import org.apache.ibatis.reflection.MetaObject;

import org.springframework.stereotype.Component;



import java.util.Date;



/**

 * @author md

 * @Desc 对实体类中使用的自动填充注解进行编写

 * @date 2020/10/26 17:29

 */

// 加入注解才能生效

@Component

public class MyMetaObjectHandler implements MetaObjectHandler {



    @Override

    public void insertFill(MetaObject metaObject) {

        this.setFieldValByName("createTime", new Date(), metaObject);

        this.setFieldValByName("updateTime", new Date(), metaObject);

    }



    @Override

    public void updateFill(MetaObject metaObject) {

        this.setFieldValByName("updateTime", new Date(), metaObject);

    }

}

4）测试

@Test

    void save(){

        // 由于id加的有注解，这里就不用赋值了

        Student student = new Student();

        student.setName("韩立");

        student.setAge(11);

        // 时间自动填充

        mapper.insert(student);

}

5）更新

当该字段发生变化的时候时间会自动更新。

@Test

    void update(){

        Student student = mapper.selectById(1001);

        student.setName("韩信");

        mapper.updateById(student);

}

四、@TableLogic注解

在很多应用中，数据并不是真的被删除，而是标记为已删除状态。@TableLogic注解用于标识逻辑删除字段，通常配合逻辑删除功能使用。

1、逻辑删除

物理删除：  真实删除，将对应数据从数据库中删除，之后查询不到此条被删除的数据。

逻辑删除：  假删除，将对应数据中代表是否被删除字段的状态修改为“被删除状态”，之后在数据库中仍旧能看到此条数据记录。

使用场景：  可以进行数据恢复。

2、实现逻辑删除

step1：  数据库中创建逻辑删除状态列。

step2：  实体类中添加逻辑删除属性。

@TableLogic

@TableField(value = "is_deleted")

private Integer deleted;

3、测试

测试删除：  删除功能被转变为更新功能。

-- 实际执行的SQL

update user set is_deleted=1 where id = 1 and is_deleted=0

测试查询：  被逻辑删除的数据默认不会被查询。

-- 实际执行的SQL

select id,name,is_deleted from user where is_deleted=0

你还在苦恼找不到真正免费的编程学习平台吗?可以试试【云端源想】！课程视频、知识库、微实战、云实验室、一对一咨询……你想要的全部学习资源这里都有，重点是现在还是免费的！点这里即可查看！

五、@Version注解

乐观锁是一种并发控制策略，@Version注解用于标识版本号字段，确保数据的一致性。

乐观锁

标记乐观锁，通过 version 字段来保证数据的安全性，当修改数据的时候，会以 version 作为条件，当条件成立的时候才会修改成功。

version = 2

• 线程1：update … set version = 2 where version = 1


• 线程2：update … set version = 2 where version = 1

1.数据库表添加 version 字段，默认值为 1。

2.实体类添加 version 成员变量，并且添加 @Version。

package com.md.entity;



import com.baomidou.mybatisplus.annotation.*;

import com.md.enums.StatusEnum;

import lombok.Data;

import java.util.Date;



@Data

@TableName(value = "student")

public class Student {

    @TableId

    private Long id;

    @TableField(value = "name")

    private String name;

    @TableField(select = false)

    private Integer age;

    @TableField(exist = false)

    private String gender;

    @TableField(fill = FieldFill.INSERT)

    private Date createTime;

    @TableField(fill = FieldFill.INSERT_UPDATE)

    private Date updateTime;

    

    @Version

    private Integer version; //版本号

  

}

3.注册配置类

在 MybatisPlusConfig 中注册 Bean。

package com.md.config;



import com.baomidou.mybatisplus.extension.plugins.OptimisticLockerInterceptor;

import com.baomidou.mybatisplus.extension.plugins.PaginationInterceptor;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;



/**

 * @author md

 * @Desc

 * @date 2020/10/26 20:42

 */

@Configuration

public class MyBatisPlusConfig {

    /**

    * 乐观锁

    */

    @Bean

    public OptimisticLockerInterceptor optimisticLockerInterceptor(){

        return new OptimisticLockerInterceptor();

    }

}

六、@EnumValue注解

mp框架对枚举进行处理的一个注解。

使用场景：  创建枚举类，在需要存储数据库的属性上添加@EnumValue注解。

public enum SexEnum {



 MAN(1, "男"),

 WOMAN(2, "女");



 @EnumValue

 private Integer key;

}

MyBatis-Plus的注解是开发者的好帮手，它们简化了映射配置，提高了开发效率。希望以上的介绍能帮助新手朋友们快速理解和运用这些常用注解，让你们在MyBatis-Plus的世界里游刃有余！记得实践是最好的学习方式，快去动手试试吧！

你好，我是猿java。

这篇文章，我们来聊聊 Java 语法糖。

什么是语法糖？

语法糖（Syntactic Sugar）是编程语言中的一种设计概念，它指的是在语法层面上对某些操作提供更简洁、更易读的表示方式。这种表示方式并不会新增语言的功能，而只是使代码更简洁、更直观，便于开发者理解和维护。

语法糖的作用：

• 提高代码可读性：语法糖可以使代码更加贴近自然语言或开发者的思维方式，从而更容易理解。


• 减少样板代码：语法糖可以减少重复的样板代码，使得开发者可以更专注于业务逻辑。


• 降低出错率：简化的语法可以减少代码量，从而降低出错的概率。

因此，语法糖不是 Java 语言特有的，它是很多编程语言设计中的一些语法特性，这些特性使代码更加简洁易读，但并不会引入新的功能或能力。

那么，Java中有哪些语法糖呢？

Java 语法糖

1. 自动装箱与拆箱

自动装箱和拆箱 (Autoboxing and Unboxing)是 Java 5 引入的特性，用于在基本数据类型和它们对应的包装类之间自动转换。

// 自动装箱

Integer num = 10; // 实际上是 Integer.valueOf(10)



// 自动拆箱

int n = num; // 实际上是 num.intValue()

2. 增强型 for 循环

增强型 for 循环（也称为 for-each 循环）用于遍历数组或集合。

int[] numbers = {1, 2, 3, 4, 5};

for (int number : numbers) {

    System.out.println(number);

}

3. 泛型

泛型（Generics）使得类、接口和方法可以操作指定类型的对象，提供了类型安全的检查和消除了类型转换的需要。

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

list.add("Hello");

String s = list.get(0); // 不需要类型转换

4. 可变参数

可变参数（Varargs）允许在方法中传递任意数量的参数。

public void printNumbers(int... numbers) {

    for (int number : numbers) {

        System.out.println(number);

    }

}



printNumbers(1, 2, 3, 4, 5);

5. try-with-resources

try-with-resources 语句用于自动关闭资源，实现了 AutoCloseable 接口的资源会在语句结束时自动关闭。

try (BufferedReader br = new BufferedReader(new FileReader("file.txt"))) {

    System.out.println(br.readLine());

} catch (IOException e) {

    e.printStackTrace();

}

6. Lambda 表达式

Lambda 表达式是 Java 8 引入的特性，使得可以使用更简洁的语法来实现函数式接口（只有一个抽象方法的接口）。

List<String> list = Arrays.asList("a", "b", "c");

list.forEach(s -> System.out.println(s));

7. 方法引用

方法引用（Method References）是 Lambda 表达式的一种简写形式，用于直接引用已有的方法。

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

8. 字符串连接

从 Java 5 开始，Java 编译器会将字符串的连接优化为 StringBuilder 操作。

String message = "Hello, " + "world!"; // 实际上是 new StringBuilder().append("Hello, ").append("world!").toString();

9. Switch 表达式

Java 12 引入的 Switch 表达式使得 Switch 语句更加简洁和灵活。

int day = 5;

String dayName = switch (day) {

    case 1 -> "Sunday";

    case 2 -> "Monday";

    case 3 -> "Tuesday";

    case 4 -> "Wednesday";

    case 5 -> "Thursday";

    case 6 -> "Friday";

    case 7 -> "Saturday";

    default -> "Invalid day";

};

10. 类型推断 (Type Inference)

Java 10 引入了局部变量类型推断，通过 var 关键字来声明变量，编译器会自动推断变量的类型。

var list = new ArrayList<String>();

list.add("Hello");

这些语法糖使得 Java 代码更加简洁和易读，但需要注意的是，它们并不会增加语言本身的功能，只是对已有功能的一种简化和封装。

总结

本文，我们介绍了 Java 语言中的一些语法糖，从上面的例子可以看出，Java 语法糖只是一些简化的语法，可以使代码更简洁易读，而本身并不增加新的功能。

学习交流

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

实现即时通讯主要有四种方式，它们分别是短轮询、长轮询、长连接、WebSocket

1. 短轮询

1.1 说明

传统的web通信模式。后台处理数据，需要一定时间，前端想要知道后端的处理结果，就要不定时的向后端发出请求以获得最新情况，得到想要的结果，或者超出规定的最长时间就终止再发请求。

1.2 优点：

前后端程序编写比较容易

1.3 缺点：

• 效率低：轮询的请求间隔时间一般是固定的，无论服务器是否有新的数据，都需要等待一段固定的时间。当数据更新的频率较低时，大部分请求都是无效的；


• 实时性差：如果数据在两次请求间发生了更新，那么用户只能在下一次轮询时才能得到最新数据；


• 浪费资源：高频率的操作功能，或者页面访问，导致的大量用户使用轮询时，会占用大量的网络资源，降低整体网络速度

1.4 基础实现：

每隔一段时间发送一个请求即可，得到想要的结果，或者超出规定的最长时间就终止再发请求。

let count = 0;

const timer = null;

// 超时时间

const MAX_TIME = 10 * 1000;

// 心跳间隙

const HEARTBEAT_INTERVAL = 1000; 



/**

 * @description: 模拟请求后端数据 （第6次时返回true）

 */

const fetchData = () => {

  return new Promise((resolve, reject) => {

    setTimeout(() => {

      console.log('fetch data...', count)

      count += 1 

      if(count === 5) {

        resolve(true);

      }else {

        resolve(false);

      }

    }, 1000)

  });

};



/**

 * @description: 异步轮询，当超时时或者接口返回true时，中断轮询

 */

const doSomething = async () => {

  try {

    let startTime = 0;

    const timer = setInterval(async ()=>{

      const res = await fetchData();

      startTime += HEARTBEAT_INTERVAL;

      if(res || startTime > MAX_TIME) {

        clearInterval(timer)

      }

    }, HEARTBEAT_INTERVAL)



  } catch (err) {

    console.log(err);

  }

};



doSomething();

2. 长轮询

2.1 说明

客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求

长轮询的实现原理与轮询类似，只是客户端的请求会保持打开状态，直到服务器返回响应或超时。在服务器端，可以使用阻塞方式处理长轮询请求，即服务器线程会一直等待直到有新的数据或事件，然后返回响应给客户端。客户端收到响应后，可以处理数据或事件，并随后发送下一个长轮询请求。

2.2 优点

长轮询相较于轮询技术来说，减少了不必要的网络流量和请求次数，降低了服务器和客户端的资源消耗

2.3 缺点

但是相对于传统的轮询技术，长轮询的实现更加复杂，并且需要服务器支持长时间保持连接的能力。

2.4 基础实现

超时和未得到想要的结果都需要重新执行原方法（递归实现）

async function subscribe() {

  let response = await fetch("/subscribe");



  if (response.status == 502) {

    // 状态 502 是连接超时错误，

    // 连接挂起时间过长时可能会发生，

    // 远程服务器或代理会关闭它

    // 让我们重新连接

    await subscribe();

  } else if (response.status != 200) {

    // 一个 error —— 让我们显示它

    showMessage(response.statusText);

    // 一秒后重新连接

    await new Promise(resolve => setTimeout(resolve, 1000));

    await subscribe();

  } else {

    // 获取并显示消息

    let message = await response.text();

    showMessage(message);

    // 再次调用 subscribe() 以获取下一条消息

    await subscribe();

  }

}



subscribe();

3. 长链接

3.1 说明

HTTP keep-alive 也称为 HTTP 长连接。它通过重用一个 TCP 连接来发送/接收多个 HTTP请求，来减少创建/关闭多个 TCP 连接的开销

3.1.1 为什么HTTP是短连接？

HTTP是短连接，客户端向服务器发送一个请求，得到响应后，连接就关闭。

例如，用户通过浏览器访问一个web站点上的某个网页，当网页内容加载完毕之后（已得到响应），用户可能需要花费几分钟甚至更多的时间来浏览网页内容，此时完全没有必要继续维持底层连。当用户需要访问其他网页时，再创建新的连接即可。

因此，HTTP连接的寿命通常都很短。这样做的好处是，可以极大的减轻服务端的压力。一般而言，一个站点能支撑的最大并发连接数也是有限的，

面对这么多客户端浏览器，不可能长期维持所有连接。每个客户端取得自己所需的内容后，即关闭连接，更加合理。

3.1.2 为什么要引入keep-alive（也称HTTP长连接）

通常一个网页可能会有很多组成部分，除了文本内容，还会有诸如：js、css、图片等静态资源，有时还会异步发起AJAX请求。

只有所有的资源都加载完毕后，我们看到网页完整的内容。然而，一个网页中，可能引入了几十个js、css文件，上百张图片，

如果每请求一个资源，就创建一个连接，然后关闭，代价实在太大了。

基于此背景，我们希望连接能够在短时间内得到复用，在加载同一个网页中的内容时，尽量的复用连接，这就是HTTP协议中keep-alive属性的作用。

• HTTP 1.0 中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；


• HTTP 1.1 中默认启用Keep-Alive，如果加入"Connection: close "，才关闭

注意：这里复用的是 TCP连接，并不是复用request

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接

4. WebSocket

4.1 说明

Websocket是基于HTTP协议的，在和服务端建立了链接后，服务端有数据有了变化后会主动推送给前端；

一般可以用于 股票交易行情分析、聊天室、在线游戏，替代轮询和长轮询。

4.2 优点

请求响应快，不浪费资源。（传统的http请求，其并发能力都是依赖同时发起多个TCP连接访问服务器实现的(因此并发数受限于浏览器允许的并发连接数)，而websocket则允许我们在一条ws连接上同时并发多个请求，即在A请求发出后A响应还未到达，就可以继续发出B请求。由于TCP的慢启动特性（新连接速度上来是需要时间的），以及连接本身的握手损耗，都使得websocket协议的这一特性有很大的效率提升；http协议的头部太大，且每个请求携带的几百上千字节的头部大部分是重复的，websocket则因为复用长连接而没有这一问题。）

4.3 缺点

• 主流浏览器支持的Web Socket版本不一致；


• 服务端没有标准的API。

4.4 基础实现

这里使用了一个 网页和打印app的通信举例（部分敏感代码已省略）

const printConnect = () => {

    try {

      const host = 'ws://localhost:13888'

      cloundPrintInfo.webSocket = new WebSocket(host)



      // 通信

      cloundPrintInfo.webSocket.onopen = () => {

        // 获取打印机列表

        cloundPrintInfo.webSocket.send(

        JSON.stringify({

          cmd: 'getPrinters',

          version: '1.0',

        })

      )

      }



      // 通信返回

      cloundPrintInfo.webSocket.onmessage = (msg: any) => {

        

        const { data: returnData } = msg

     

        // code  1000: 全部成功  1001: 部分失败  1002: 全部失败

        const { cmd } = JSON.parse(`${returnData}`)

       

        // 获取打印机数据

        if (cmd === 'GETPRINTERS') {

          printerInfoSet(returnData)

        }



        // 处理发送打印请求结果

        if (cmd === 'PRINT') {

          handlePrintResult(returnData)

        }



        // 批量推送打印结果

        if (cmd === 'NOTIFYPRINTRESULT') {

          cloudPrintTip(returnData)

        }

      }



      // 通信失败

      cloundPrintInfo.webSocket.onerror = () => {

        printClose()

      }



      // 关闭通信

      cloundPrintInfo.webSocket.onclose = () => {

        printClose()

      }

    } catch (exception) {

      console.log('建立连接失败', exception)

      printClose()

    }

  }

在实际应用中，你可能需要处理更复杂的情况，比如重连逻辑、心跳机制来保持连接活跃、以及安全性问题等

重连逻辑：当WebSocket连接由于网络问题或其他原因断开时，客户端可能需要自动尝试重新连接

var socket;

var reconnectInterval = 5000; // 重连间隔时间，例如5秒



function connect() {

  socket = new WebSocket('ws://localhost:3000');



  socket.onopen = function(event) {

    console.log('Connected to the WebSocket server');

  };



  socket.onclose = function(event) {

    console.log('WebSocket connection closed. Reconnecting...');

    setTimeout(connect, reconnectInterval); // 在指定时间后尝试重连

  };



  socket.onerror = function(error) {

    console.error('WebSocket error:', error);

    socket.close(); // 确保在错误后关闭连接，触发重连

  };

}



connect(); // 初始连接

心跳机制：指定期发送消息以保持连接活跃的过程。这可以防止代理服务器或负载均衡器因为长时间的不活动而关闭连接

function heartbeat() {

  if (socket.readyState === WebSocket.OPEN) {

    socket.send('ping'); // 发送心跳消息，内容可以是'ping'

  }

}



// 每30秒发送一次心跳

var heartbeatInterval = setInterval(heartbeat, 30000);



// 清除心跳定时器，通常在连接关闭时调用

function clearHeartbeat() {

  clearInterval(heartbeatInterval);

}



socket.onclose = function(event) {

  clearHeartbeat();

};

4种对比

从兼容性角度考虑，短轮询>长轮询>长连接SSE>WebSocket；

从性能方面考虑，WebSocket>长连接SSE>长轮询>短轮询。

参考文章：

• Http——Keep-Alive机制

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. 总结

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

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

方案一：定时任务

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

@Component

public class OrderSchedule {

    @Autowired

    private OrderService orderService;



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

    public void cancelUnpaidOrders() {

        LocalDateTime now = LocalDateTime.now();

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

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

        orderList.forEach(order -> {

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

                idList.add(order.getId());

          }

        });

        orderService.cancelOrderList(idList);

        }

}

方案二：延迟队列

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

@Service

public class OrderService {



    @Autowired

    private RabbitTemplate rabbitTemplate;



    public void createOrder(Order order) {

        // 保存数据库

        saveOrder(order);



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

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

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

            return message;

        });

    }

}



@Component

public class OrderDelayConsumer {



    @Autowired

    private OrderService orderService;



    @RabbitHandler

    @RabbitListener(queues = "orderDelayQueue")

    public void cancelOrder(String orderId) {

        // 取消订单

        orderService.cancelOrder(orderId);

    }

}

方案三：redis过期事件

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

@Service

public class OrderService {



    @Autowired

    private StringRedisTemplate redisTemplate;



    public void createOrder(Order order) {

        // 保存订单至数据库

        saveOrder(order);



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

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

    }



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

    public void onOrderKeyExpired(String orderId) {

        cancelOrder(orderId);

    }

}

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

最后总结：

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

你好呀，我是歪歪。

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

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

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

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

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

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

if(reqDto.getField1() 

    && reqDto.getField2()!=null

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

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

    }

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

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

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

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

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

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

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

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

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

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

ReqDto reqDto = new ReqDto();

reqDto.setField1(null);

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

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

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

ReqDto reqDto = ReqDto.builder()

        .field2("why")

        .field3("max")

        .build();

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

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

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

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

是 builder 在里面搞事情了？

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

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

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

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

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

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

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    @Builder.Default

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

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

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

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

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

明显是不同的处理方式。

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

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

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

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

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

private Boolean field1 = true;

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

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

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

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

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

打个标，就是 @Builder.Default。

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

吃个瓜

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

github.com/projectlomb…

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

简单的一起吃个瓜。

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

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

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

MyClass myClass = new MyClass();

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我们把目光放到这里来：

@NoArgsConstructor，这是个啥东西？

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

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

这个算一次了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

projectlombok.org/changelog

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

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

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

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

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

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

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

编译时注解

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

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

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

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

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

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

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

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

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

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

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

lombok.core.handlers.LoggingFramework

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

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

比如 log4j 是这样的：

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

而 SLF4J 是这样的：

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

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

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

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

javax.annotation.processing.AbstractProcessor

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

荒腔走板

周末去了一趟都江堰。

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

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

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

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

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

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

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

成都不能没有都江堰。

李冰父子，配享太庙。

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

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

什么是JWT?

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

这个就是JWT

JWT 全称JSON Web Token

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

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

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

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

为什么说JWT很烂？

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

• 用户注册网站


• 用户登录网站


• 用户点击并执行操作


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

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

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


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


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

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

大小

这个方面毋庸置疑。

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

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

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

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

冗余签名

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

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

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

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

令牌撤销问题

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

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

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

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

可能存在陈旧数据

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

JWT通常不加密

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

安全问题

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

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

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

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

总结

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

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

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

首发公众号:【赵侠客】

引言

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

理由一、for性能更好

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

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

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

@State(Scope.Thread)

public class ForBenchmark {

    private List<Integer> ids ;

    @Setup

    public void setup() {

        ids = new ArrayList<>();

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

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

    }

    @TearDown

    public void tearDown() {

        ids = new ArrayList<>();

    }

    @Benchmark

    public void testFor() {

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

            Integer id = ids.get(i);

        }

    }



    @Benchmark

    public void testStreamforEach() {

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

            Integer id=x;

        });

    }



    @Test

    public void testMyBenchmark() throws Exception {

        Options options = new OptionsBuilder()

                .include(ForBenchmark.class.getSimpleName())

                .forks(1)

                .threads(1)

                .warmupIterations(1)

                .measurementIterations(1)

                .mode(Mode.Throughput)

                .build();

        new Runner(options).run();

    }

}

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

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

所以可以得出结论：

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

理由二、for占用内存更小

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

• 使用for遍历

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

int sum = 0;

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

    sum +=ids.get(i);

}

System.gc();

//GC日志

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

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

• 使用stream

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

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

System.gc();

//GC日志

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

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

理由三、for更易控制流程

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

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

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

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

    if(i>1){

        return;

    }

});

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

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

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

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

        return;

    }

}

输出：

forEach-1

forEach-2

forEach-3

==

for-1

for-2

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

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

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

Integer sum=0;

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

    sum++;

}



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

    //报错

    sum++;

});

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

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

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

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

});

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

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

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

public void testException() throws Exception {

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

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

      //直接抛出Exception

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

  }



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

      try {

          //必须捕获Exception

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

      } catch (Exception e) {

          throw new RuntimeException(e);

      }

  });

}



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

    return a / b;

}