常见 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() { } }
参考资料
- Null：价值 10 亿美元的错误: https://www.infoq.cn/article/uyyos0vgetwcgmo1ph07
- 双重检查锁失效声明: https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
- 每个程序员都应该知道的延迟数字: https://colin-scott.github.io/personal_website/research/interactive_latency.html
团队介绍
我们是淘天集团物流技术基础技术团队，NBF（新零售开放服务框架），从APaas，BPaas到DPaas，提供完整的中台开发框架。
