常见 Java 代码缺陷及规避方式（下）-阿里云开发者社区

常见 Java 代码缺陷及规避方式（中）：https://developer.aliyun.com/article/1480647

特殊异常的处理

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() {
    }
}