常见 Java 代码缺陷及规避方式

在日常开发过程中，我们会碰到各种各样的代码缺陷或者 Bug，比如 NPE、 线程安全问题、异常处理等。这篇文章总结了一些常见的问题及应对方案，希望能帮助到大家。

问题列表

▐  空指针异常

NPE 或许是编程语言中最常见的问题，被 Null 的发明者托尼·霍尔（Tony Hoare）称之为十亿美元的错误。在 Java 中并没有内置的处理 Null 值的语法，但仍然存在一些相对优雅的方式能够帮助我们的规避 NPE。

• 使用 JSR-305/jetbrain 等注解

1. NotNull

2. Nullable

通过在方法参数、返回值、字段等位置显式标记值是否可能为 Null，配合代码检查工具，能够在编码阶段规避绝大部分的 NPE 问题，建议至少在常用方法或者对外 API 中使用该注解，能够对调用方提供显著的帮助。

• 用 Optional 处理链式调用

Optional 源于 Guava 中的 Optional 类，后 Java 8 内置到 JDK 中。Optional 一般作为函数的返回值，强制提醒调用者返回值可能不存在，并且能够通过链式调用优雅的处理空值。

public class OptionalExample {
 
 
    public static void main(String[] args) {
        // 使用传统空值处理方式
        User user = getUser();
        String city = "DEFAULT";
        if (user != null && user.isValid()) {
            Address address = user.getAddress();
            if (adress != null) {
                city = adress.getCity();
            }
        }
        System.out.println(city);
 
 
        // 使用 Optional 的方式
        Optional<User> optional = getUserOptional();
        city = optional.filter(User::isValid)
                .map(User::getAddress)
            .map(Adress::getCity)
              .orElse("DEFAULT")
        System.out.println(city);
    }
 
 
    @Nullable
    public static User getUser() {
        return null;
    }
 
 
    public static Optional<User> getUserOptional() {
        return Optional.empty();
    }
 
 
    @Data
    public static class User {
        private Adress address;
        private boolean valid;
    }
 
 
    @Data
    public static class Address {
        private String city;
    }
}

• 用 Objects.equals(a,b) 代替 a.equals(b)

equals方法是 NPE 的高发地点，用 Objects.euqals来比较两个对象，能够避免任意对象为 null 时的 NPE。

• 使用空对象模式

空对像模式通过一个特殊对象代替不存在的情况，代表对象不存在时的默认行为模式。常见例子：

用 Empty List 代替 null，EmptyList 能够正常遍历：

public class EmptyListExample {
 
 
    public static void main(String[] args) {
        List<String> listNullable = getListNullable();
        if (listNullable != null) {
            for (String s : listNullable) {
                System.out.println(s);
            }
        }
 
 
        List<String> listNotNull = getListNotNull();
        for (String s : listNotNull) {
            System.out.println(s);
        }
    }
 
 
    @Nullable
    public static List<String> getListNullable() {
        return null;
    }
 
 
    @NotNull
    public static List<String> getListNotNull() {
        return Collections.emptyList();
    }
}

空策略

public class NullStrategyExample {
 
 
    private static final Map<String, Strategy> strategyMap = new HashMap<>();
 
 
    public static void handle(String strategy, String content) {
        findStrategy(strategy).handle(content);
    }
 
 
    @NotNull
    private static Strategy findStrategy(String strategyKey) {
        return strategyMap.getOrDefault(strategyKey, new DoNothing());
    }
 
 
    public interface Strategy {
        void handle(String s);
    }
 
 
    // 当找不到对应策略时, 什么也不做
    public static class DoNothing implements Strategy {
        @Override
        public void handle(String s) {
 
 
        }
    }
}

▐  对象转化

在业务应用中，我们的代码结构往往是多层次的，不同层次之间经常涉及到对象的转化，虽然很简单，但实际上繁琐且容易出错。

反例 1：

public class UserConverter {
 
 
    public static UserDTO toDTO(UserDO userDO) {
        UserDTO userDTO = new UserDTO();
        userDTO.setAge(userDO.getAge());
        // 问题 1: 自己赋值给自己
        userDTO.setName(userDTO.getName());
        return userDTO;
    }
 
 
    @Data
    public static class UserDO {
        private String name;
        private Integer age;
        // 问题 2: 新增字段未赋值
        private String address;
    }
 
 
    @Data
    public static class UserDTO {
        private String name;
        private Integer age;
    }
}

反例2：

public class UserBeanCopyConvert {
 
 
    public UserDTO toDTO(UserDO userDO) {
        UserDTO userDTO = new UserDTO();
        // 用反射复制不同类型对象.
        // 1. 重构不友好, 当我要删除或修改 UserDO 的字段时, 无法得知该字段是否通过反射被其他字段依赖
        BeanUtils.copyProperties(userDO, userDTO);
        return userDTO;
    }
}

• 使用 Mapstruct

Mapstruct 使用编译期代码生成技术，根据注解, 入参，出参自动生成转化，代码，并且支持各种高级特性，比如：

1. 未映射字段的处理策略，在编译期发现映射问题

2. 复用工具，方便字段类型转化

3. 生成 spring Component 注解，通过 spring 管理

4. 等等其他特性

@Mapper(
    componentModel = "spring",
    unmappedSourcePolicy = ReportingPolicy.ERROR,
    unmappedTargetPolicy = ReportingPolicy.ERROR,
    // convert 逻辑依赖 DateUtil 做日期转化
    uses = DateUtil.class
)
public interface UserConvertor  {
 
 
    UserDTO toUserDTO(UserDO userDO);
 
 
    @Data
    class UserDO {
        private String name;
        private Integer age;
        //private String address;
        private Date birthDay;
    }
 
 
    @Data
    class UserDTO {
        private String name;
        private Integer age;
        private String birthDay;
    }
 
 
}
 
 
public class DateUtil {
    public static String format(Date date) {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd");
        return simpleDateFormat.format(date);
    }
}

使用示例：

@RequiredArgsConstructor
@Component
public class UserService {
    private final UserDao userDao;
    private final UserCovertor userCovertor;
 
 
    public UserDTO getUser(String userId){
        UserDO userDO = userDao.getById(userId);
        return userCovertor.toUserDTO(userDO);
    }
}

编译期校验：

生成的代码：

@Generated(
    value = "org.mapstruct.ap.MappingProcessor",
    date = "2023-12-18T20:17:00+0800",
    comments = "version: 1.3.1.Final, compiler: javac, environment: Java 11.0.12 (GraalVM Community)"
)
@Component
public class UserConvertorImpl implements UserConvertor {
 
 
    @Override
    public UserDTO toUserDTO(UserDO userDO) {
        if ( userDO == null ) {
            return null;
        }
 
 
        UserDTO userDTO = new UserDTO();
 
 
        userDTO.setName( userDO.getName() );
        userDTO.setAge( userDO.getAge() );
        userDTO.setBirthDay( DateUtil.format( userDO.getBirthDay() ) );
 
 
        return userDTO;
    }
}

▐  线程安全问题

JVM 的内存模型十分复杂，难以理解, <<Java 并发编程实战>>告诉我们，除非你对 JVM 的线程安全原理十分熟悉，否则应该严格遵守基本的 Java 线程安全规则，使用 Java 内置的线程安全的类及关键字。

• 熟练使用线程安全类

ConcurrentHashMap

反例：

map.get 以及 map.put 操作是非原子操作，多线程并发修改的情况下可能导致一致性问题。比如线程 A 调用 append 方法，在第 6 行时，线程 B 删除了 key。

public class ConcurrentHashMapExample {
    private Map<String, String> map = new ConcurrentHashMap<>();
 
 
    public void appendIfExists(String key, String suffix) {
        String value = map.get(key);
        if (value != null) {
            map.put(key, value + suffix);
        }
    }
}

正例：

public class ConcurrentHashMapExample {
    private Map<String, String> map = new ConcurrentHashMap<>();
 
 
    public void append(String key, String suffix) {
        // 使用 computeIfPresent 原子操作
        map.computeIfPresent(key, (k, v) -> v + suffix);
    }
}

• 保证变更的原子性

反例：

@Getter
public class NoAtomicDiamondParser {
 
 
    private volatile int start;
 
 
    private volatile int end;
 
 
    public NoAtomicDiamondParser() {
        Diamond.addListener("dataId", "groupId", new ManagerListenerAdapter() {
            @Override
            public void receiveConfigInfo(String s) {
                JSONObject jsonObject = JSON.parseObject(s);
                start = jsonObject.getIntValue("start");
                end  = jsonObject.getIntValue("end");
            }
        });
    }
}
 
 
public class MyController{
 
 
    private final NoAtomicDiamondParser noAtomicDiamondParser;
 
 
    public void handleRange(){
        // end 读取的旧值, start 读取的新值, start 可能大于 end
        int end = noAtomicDiamondParser.getEnd();
        int start = noAtomicDiamondParser.getStart();
    }
}

正例：

@Getter
public class AtomicDiamondParser {
 
 
    private volatile Range range;
 
 
    public AtomicDiamondParser() {
        Diamond.addListener("dataId", "groupId", new ManagerListenerAdapter() {
            @Override
            public void receiveConfigInfo(String s) {
                range = JSON.parseObject(s, Range.class);
            }
        });
    }
 
 
    @Data
    public static class Range {
        private int start;
        private int end;
    }
}
 
 
public class MyController {
 
 
    private final AtomicDiamondParser atomicDiamondParser;
 
 
    public void handleRange() {
        Range range = atomicDiamondParser.getRange();
        System.out.println(range.getStart());
        System.out.println(range.getEnd());
    }
}

• 使用不可变对象

当一个对象是不可变的，那这个对象内就自然不存在线程安全问题，如果需要修改这个对象，那就必须创建一个新的对象，这种方式适用于简单的值对象类型，常见的例子就是 java 中的 String 和 BigDecimal。对于上面一个例子，我们也可以将 Range 设计为一个通用的值对象。

正例：

@Getter
public class AtomicDiamondParser {
 
 
    private volatile Range range;
 
 
    public AtomicDiamondParser() {
        Diamond.addListener("dataId", "groupId", new ManagerListenerAdapter() {
            @Override
            public void receiveConfigInfo(String s) {
                JSONObject jsonObject = JSON.parseObject(s);
                int start = jsonObject.getIntValue("start");
                int end  = jsonObject.getIntValue("end");
                range = new Range(start, end);
            }
        });
    }
 
 
    // lombok 注解会保证 Range 类的不变性
    @Value
    public static class Range {
        private int start;
        private int end;
    }
}

• 正确性优先于性能

不要因为担心性能问题而放弃使用 synchronized，volatile 等关键字，或者采用一些非常规写法

反例 双重检查锁：

class Foo { 
  // 缺少 volatile 关键字
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
      synchronized(this) {
        if (helper == null) 
          helper = new Helper();
      }    
    return helper;
    }
}

在上述例子中，在 helper 字段上增加 volatile 关键字，能够在 java 5 及之后的版本中保证线程安全。

正例：

class Foo { 
  private volatile Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
      synchronized(this) {
        if (helper == null) 
          helper = new Helper();
      }    
    return helper;
    }
}

正例3（推荐）：

class Foo { 
  private Helper helper = null;
  public synchronized Helper getHelper() {
      if (helper == null) 
          helper = new Helper();
      }    
    return helper;
}

并不严谨的 Diamond Parser：

/**
 * 省略异常处理等其他逻辑
 */
@Getter
public class DiamondParser {
 
 
    // 缺少 volatile 关键字
    private Config config;
 
 
    public DiamondParser() {
        Diamond.addListener("dataId", "groupId", new ManagerListenerAdapter() {
            @Override
            public void receiveConfigInfo(String s) {
                config = JSON.parseObject(s, Config.class);
            }
        });
    }
 
 
    @Data
    public static class Config {
        private String name;
    }
}

这种 Diamond 写法可能从来没有发生过线上问题，但这种写法也确实是不符合 JVM 线程安全原则。未来某一天你的代码跑在另一个 JVM 实现上，可能就有问题了。

▐  线程池使用不当

反例 1：

public class ThreadPoolExample {
 
 
    // 没有任何限制的线程池, 使用起来很方便, 但当一波请求高峰到达时, 可能会创建大量线程, 导致系统崩溃
    private static Executor executor = Executors.newCachedThreadPool();
 
 
}

反例 2：

public class StreamParallelExample {
 
 
    public List<String> batchQuery(List<String> ids){
        // 看上去很优雅, 但 ForkJoinPool 的队列是没有大小限制的, 并且线程数量很少, 如果 ids 列表很大可能导致 OOM
        // parallelStream 更适合计算密集型任务, 不要在任务中做远程调用
        return ids.parallelStream()
            .map(this::queryFromRemote)
            .collect(Collectors.toList());
    }
 
 
    private String queryFromRemote(String id){
       // 从远程查询
    }
}

• 手动创建线程池

正例：

public class ManualCreateThreadPool {
 
 
    // 手动创建资源有限的线程池
    private Executor executor = new ThreadPoolExecutor(10, 10, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<>(1000),
        new ThreadFactoryBuilder().setNameFormat("work-%d").build());
}

▐  异常处理不当

和 NPE 一样，异常处理也同样是我们每天都需要面对的问题，但很多代码中往往会出现：

反例 1：

重复且繁琐的的异常处理逻辑

@Slf4j
public class DuplicatedExceptionHandlerExample {
 
 
    private UserService userService;
 
 
    public User query(String id) {
        try {
            return userService.query(id);
        } catch (Exception e) {
            log.error("query error, userId: {}", id, e);
            return null;
        }
    }
 
 
    public User create(String id) {
        try {
            return userService.create(id);
        } catch (Exception e) {
            log.error("query error, userId: {}", id, e);
            return null;
        }
    }
}

反例 2：

异常被吞掉或者丢失部分信息

@Slf4j
public class ExceptionShouldLogOrThrowExample {
 
 
    private UserService userService;
 
 
    public User query(String id) {
        try {
            return userService.query(id);
        } catch (Exception e) {
            // 异常被吞并, 问题被隐藏
            return null;
        }
    }
 
 
    public User create(String id) {
        try {
            return userService.create(id);
        } catch (Exception e) {
            // 堆栈丢失, 后续难以定位问题
            log.error("query error, userId: {}, error: {}", id,e.getMessage() );
            return null;
        }
    }
}

反例 3：

对外抛出未知异常, 导致调用方序列化失败

public class OpenAPIService {
 
 
    public void handle(){
        // HSF 服务对外抛出 client 中未定义的异常, 调用方反序列化失败
        throw new InternalSystemException("");
    }
}

• 通过 AOP 统一异常处理

1. 避免未知异常抛给调用方, 将未知异常转为 Result 或者通用异常类型

2. 统一异常日志的打印和监控

• 处理 Checked Exception

Checked Exception 是在编译期要求必须处理的异常，也就是非 RuntimeException 类型的异常，但 Java Checked 的异常给接口的调用者造成了一定的负担，导致异常声明层层传递，如果顶层能够处理该异常，我们可以通过 lombok 的 @SneakyThrows 注解规避 Checked exception

• Try catch 线程逻辑

反例：

@RequiredArgsConstructor
public class ThreadNotTryCatch {
    private final ExecutorService executorService;
    public void handle() {
        executorService.submit(new Runnable() {
            @Override
            public void run() {
                // 未捕获异常, 线程直接退出, 异常信息丢失
                remoteInvoke();
            }
        });
    }
}

正例：

@RequiredArgsConstructor
@Slf4j
public class ThreadNotTryCatch {
    private final ExecutorService executorService;
 
 
    public void handle() {
        executorService.submit(new Runnable() {
            @Override
            public void run() {
                try {
                    remoteInvoke();
                } catch (Exception e) {
                    log.error("handle failed", e);
                }
            }
        });
    }
}

• 特殊异常的处理

InterruptedException 一般是上层调度者主动发起的中断信号，例如某个任务执行超时，那么调度者通过将线程置为 interuppted 来中断任务，对于这类异常我们不应该在 catch 之后忽略，应该向上抛出或者将当前线程置为 interuppted。

反例：

public class InterruptedExceptionExample {
    private ExecutorService executorService = Executors.newSingleThreadExecutor();
 
 
    public void handleWithTimeout() throws InterruptedException {
        Future<?> future = executorService.submit(() -> {
            try {
                // sleep 模拟处理逻辑
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                System.out.println("interrupted");
            }
            System.out.println("continue task");
            // 异常被忽略, 继续处理
        });
        // 等待任务结果, 如果超过 500ms 则中断
        Thread.sleep(500);
        if (!future.isDone()) {
            System.out.println("cancel");
            future.cancel(true);
        }
    }
}

• 避免 catch Error

不要吞并 Error，Error 设计本身就是区别于异常，一般不应该被 catch，更不能被吞掉。举个例子，OOM 有可能发生在任意代码位置，如果吞并 Error，让程序继续运行，那么以下代码的 start 和 end 就无法保证一致性。

public class ErrorExample {
 
 
    private Date start;
 
 
    private Date end;
 
 
    public synchronized void update(long start, long end) {
        if (start > end) {
            throw new IllegalArgumentException("start after end");
        }
        this.start = new Date(start);
        // 如果 new Date(end) 发生 OOM, start 有可能大于 end
        this.end = new Date(end);
    }
}

▐  Spring Bean 隐式依赖

• 反例 1: SpringContext 作为静态变量

UserController 和 SpringContextUtils 类没有依赖关系， SpringContextUtils.getApplication() 可能返回空。并且 Spring 非依赖关系的 Bean 之间的初始化顺序是不确定的，虽然可能当前初始化顺序恰好符合期望，但后续可能发生变化。

@Component
public class SpringContextUtils {
 
 
    @Getter
    private static ApplicationContext applicationContext;
 
 
    public SpringContextUtils(ApplicationContext context) {
        applicationContext = context;
    }
}
 
 
@Component
public class UserController {
 
 
    public void handle(){
        MyService bean = SpringContextUtils.getApplicationContext().getBean(MyService.class);
    }
}

反例 2: Switch 在 Spring Bean 中注册, 但通过静态方式读取

@Component
public class SwitchConfig {
 
 
    @PostConstruct
    public void init() {
        SwitchManager.register("appName", MySwitch.class);
    }
 
 
    public static class MySwitch {
        @AppSwitch(des = "config", level = Switch.Level.p1)
        public static String config;
    }
}
 
 
@Component
public class UserController{
 
 
    public String getConfig(){
        // UserController 和 SwitchConfig 类没有依赖关系, MySwitch.config 可能还没有初始化
        return MySwitch.config;
    }
}

通过 SpringBeanFactory 保证初始化顺序：

public class PreInitializer implements BeanFactoryPostProcessor, PriorityOrdered {
 
 
  @Override
  public int getOrder() {
    return Ordered.HIGHEST_PRECEDENCE;
  }
 
 
  @Override
  public void postProcessBeanFactory(
    ConfigurableListableBeanFactory beanFactory) throws BeansException {
       try {
        SwitchManager.init(应用名, 开关类.class);
      } catch (SwitchCenterException e) {
        // 此处抛错最好阻断程序启动，避免开关读不到持久值引发问题
    } catch (SwitchCenterError e) {
        System.exit(1);
    }
    }
}

@Component
public class SpringContextUtilPostProcessor implements BeanFactoryPostProcessor, PriorityOrdered, ApplicationContextAware {
 
 
    private ApplicationContext applicationContext;
 
 
    @Override
    public int getOrder() {
        return Ordered.HIGHEST_PRECEDENCE;
    }
 
 
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
            throws BeansException {
        SpringContextUtils.setApplicationContext(applicationContext);
    }
 
 
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        this.applicationContext = applicationContext;
    }
}

▐  内存/资源泄漏

虽然 JVM 有垃圾回收机制，但并不意味着内存泄漏问题不存在，一般内存泄漏发生在在长时间持对象无法释放的场景，比如静态集合，内存中的缓存数据，运行时类生成技术等。

• LoadingCache 代替全局 Map

@Service
public class MetaInfoManager {
 
 
    // 对于少量的元数据来说, 放到内存中似乎并无大碍, 但如果后续元数据量增大, 则大量对象则内存中无法释放, 导致内存泄漏
    private Map<String, MetaInfo> cache = new HashMap<>();
 
 
    public MetaInfo getMetaInfo(String id) {
        return cache.computeIfAbsent(id, k -> loadFromRemote(id));
    }
 
 
    private LoadingCache<String, MetaInfo> loadingCache = CacheBuilder.newBuilder()
        // loadingCache 设置最大 size 或者过期时间, 能够限制缓存条目的数量
        .maximumSize(1000)
        .build(new CacheLoader<String, MetaInfo>() {
            @Override
            public MetaInfo load(String key) throws Exception {
                return loadFromRemote(key);
            }
        });
 
 
    public MetaInfo getMetaInfoFromLoadingCache(String id) {
        return loadingCache.getUnchecked(id);
    }
 
 
    private MetaInfo loadFromRemote(String id) {
        return null;
    }
 
 
    @Data
    public static class MetaInfo {
        private String id;
        private String name;
    }
}

• 谨慎使用运行时类生成技术

Cglib, Javasisit 或者 Groovy 脚本会在运行时创建临时类, Jvm 对于类的回收条件十分苛刻, 所以这些临时类在很长一段时间都不会回收, 直到触发 FullGC.

• 使用 Try With Resource

使用 Java 8 try wiht Resource 语法：

public class TryWithResourceExample {
 
 
    public static void main(String[] args) throws IOException {
        try (InputStream in = Files.newInputStream(Paths.get(""))) {
            // read
        }
    }
}

▐  性能问题

URL 的 hashCodeeuqals 方法

URL 的 hashCode，equals 方法的实现涉及到了对域名 ip 地址解析，所以在显示调用或者放到 Map 这样的数据结构中，有可能触发远程调用。用 URI 代替 URL 则可以避免这个问题

反例 1：

public class URLExample {
    public void handle(URL a, URL b) {
        if (Objects.equals(a, b)) {
 
 
        }
    }
}

反例 2：

public class URLMapExample {
 
 
    private static final Map<URL, Object> urlObjectMap = new HashMap<>();
 
 
}

循环远程调用：

public class HSFLoopInvokeExample {
 
 
    @HSFConsumer
    private UserService userService;
 
 
    public List<User> batchQuery(List<String> ids){
        // 使用批量接口或者限制批量大小
       return ids.stream()
            .map(userService::getUser)
            .collect(Collectors.toList());
    }
}

• 了解常见性能指标&瓶颈

了解一些基础性能指标，有助于我们准确评估当前问题的性能瓶颈，这里推荐看一下《每个程序员都应该知道的延迟数字》。比如将字段设置为 volatile，相当于每次都需要读主存，读主存性能大概在纳秒级别，在一次 HSF 调用中不太可能成为性能瓶颈。反射相比普通操作多几次内存读取，一般认为性能较差，但是同理在一次 HSF 调用中也不太可能成为性能瓶颈。

在服务端开发中, 性能瓶颈一般集中在：

大量日志打印 大对象序列化 网络调用: 比如 HSF, HTTP 等远程调用

数据库操作

• 使用专业性能测试工具估性能

不要尝试自己实现一个简陋的性能测试，在测试代码运行过程中，编译器，JVM， 操作系统各个层级上都有可能存在你意料之外的优化，导致测试结果过于乐观。建议使用 jmh，arthas 火焰图，这样的专业工具做性能测试

反例：

public class ManualPerformanceTest {
 
 
    public void testPerformance() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 1000; i++) {
            // 这里 mutiply 没有任何副作用, 有可能被优化之后被干掉
            mutiply(10, 10);
        }
        System.out.println("avg rt: " + (System.currentTimeMillis() - start) / 1000);
    }
 
 
    private int mutiply(int a, int b) {
        return a * b;
    }
}

正例:

使用火焰图

正例 2 :

使用 jmh 评估性能

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(3)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class JMHExample {
 
 
    @Benchmark
    public void testPerformance(Blackhole bh) {
        bh.consume(mutiply(10, 10));
    }
 
 
    private int mutiply(int a, int b) {
        return a * b;
    }
}

▐  Spring 事务问题

• 注意事务注解失效的场景

当打上 @Transactional 注解的 spring bean 被注入时，spring 会用事务代理过的对象代替原对象注入。

但是如果注解方法被同一个对象中的另一个方法里面调用，则该调用无法被 Spring 干预，自然事务注解也就失效了。

@Component
public class TransactionNotWork {
 
 
    public void doTheThing() {
        actuallyDoTheThing();
    }
 
 
    @Transactional
    public void actuallyDoTheThing() {
    }
}

参考资料

1. Null：价值 10 亿美元的错误: https://www.infoq.cn/article/uyyos0vgetwcgmo1ph07

2. 双重检查锁失效声明: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

3. 每个程序员都应该知道的延迟数字: https://colin-scott.github.io/personal_website/research/interactive_latency.html

团队介绍

我们是淘天集团物流技术基础技术团队，NBF（新零售开放服务框架），从APaas，BPaas到DPaas，提供完整的中台开发框架。

¤ 拓展阅读 ¤

3DXR技术 | 终端技术 | 音视频技术

服务端技术 | 技术质量 | 数据算法