导读

在日常开发过程中,我们会碰到各种各样的代码缺陷或者 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 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 OptionalgetUserOptional() {        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) {        ListString> listNullable = getListNullable();        if (listNullable != null) {            for (String s : listNullable) {                System.out.println(s);            }        }
        ListString> listNotNull = getListNotNull();        for (String s : listNotNull) {            System.out.println(s);        }    }
    @Nullable    public static ListString> getListNullable() {        return null;    }
    @NotNull    public static ListString> getListNotNull() {        return Collections.emptyList();    }}

空策略

public class NullStrategyExample {
    private static final Map 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@Componentpublic 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)")@Componentpublic 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 的内存模型十分复杂,难以理解, >告诉我们,除非你对 JVM 的线程安全原理十分熟悉,否则应该严格遵守基本的 Java 线程安全规则,使用 Java 内置的线程安全的类及关键字。
    • 熟练使用线程安全类

    ConcurrentHashMap
    反例:
    map.get 以及 map.put 操作是非原子操作,多线程并发修改的情况下可能导致一致性问题。比如线程 A 调用 append 方法,在第 6 行时,线程 B 删除了 key。
    public class ConcurrentHashMapExample {    private Map 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 Mapmap = new ConcurrentHashMap();
        public void append(String key, String suffix) {        // 使用 computeIfPresent 原子操作        map.computeIfPresent(key, (k, v) -> v + suffix);    }}
    • 保证变更的原子性

    反例:
    @Getterpublic 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();    }}

    正例:

    @Getterpublic 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 中的 StringBigDecimal。对于上面一个例子,我们也可以将 Range 设计为一个通用的值对象。
    正例:
    @Getterpublic 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

    /** * 省略异常处理等其他逻辑 */@Getterpublic 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 ListString> batchQuery(ListString> 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:
    重复且繁琐的的异常处理逻辑
    @Slf4jpublic 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:

    异常被吞掉或者丢失部分信息
    @Slf4jpublic 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 线程逻辑

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

    正例:

    @RequiredArgsConstructor@Slf4jpublic 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 作为静态变量
    UserControllerSpringContextUtils 类没有依赖关系, SpringContextUtils.getApplication() 可能返回空。并且 Spring 非依赖关系的 Bean 之间的初始化顺序是不确定的,虽然可能当前初始化顺序恰好符合期望,但后续可能发生变化。
    @Componentpublic class SpringContextUtils {
        @Getter    private static ApplicationContext applicationContext;
        public SpringContextUtils(ApplicationContext context) {        applicationContext = context;    }}
    @Componentpublic class UserController {
        public void handle(){        MyService bean = SpringContextUtils.getApplicationContext().getBean(MyService.class);    }}

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

    @Componentpublic 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;    }}
    @Componentpublic 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);    }    }}
    @Componentpublic 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

      @Servicepublic class MetaInfoManager {
          // 对于少量的元数据来说, 放到内存中似乎并无大碍, 但如果后续元数据量增大, 则大量对象则内存中无法释放, 导致内存泄漏    private MapString, MetaInfo> cache = new HashMap();
          public MetaInfo getMetaInfo(String id) {        return cache.computeIfAbsent(id, k -> loadFromRemote(id));    }
          private LoadingCacheString, MetaInfo> loadingCache = CacheBuilder.newBuilder()        // loadingCache 设置最大 size 或者过期时间, 能够限制缓存条目的数量        .maximumSize(1000)        .build(new CacheLoaderString, 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        }    }}
      性能问题
      URLhashCodeeuqals 方法
      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 urlObjectMap = new HashMap();
        }

        循环远程调用:

        public class HSFLoopInvokeExample {
            @HSFConsumer    private UserService userService;
            public List batchQuery(List 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 干预,自然事务注解也就失效了。
        @Componentpublic 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


        0 条评论

        发表回复

        Avatar placeholder

        您的电子邮箱地址不会被公开。 必填项已用 * 标注

        此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

        蜀ICP备16001794号
        © 2014 - 2024 linpxing.cn All right reserved.