常見 Java 代碼缺陷及規避方式

在日常開發過程中，我們會碰到各種各樣的代碼缺陷或者 Bug，比如 NPE、線程安全問題、異常處理等。這篇文章總結了一些常見的問題及應對方案，希望能幫助到大家。

問題列表

空指針異常

NPE 或許是編程語言中最常見的問題，被 Null 的發明者託尼 · 霍爾（Tony Hoare）稱之爲十億美元的錯誤。在 Java 中並沒有內置的處理 Null 值的語法，但仍然存在一些相對優雅的方式能夠幫助我們的規避 NPE。

使用 JSR-305/jetbrain 等註解

NotNull
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 使用編譯期代碼生成技術，根據註解, 入參，出參自動生成轉化，代碼，並且支持各種高級特性，比如：

未映射字段的處理策略，在編譯期發現映射問題；
複用工具，方便字段類型轉化；
生成 spring Component 註解，通過 spring 管理；
等等其他特性；

@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 統一異常處理

避免未知異常拋給調用方, 將未知異常轉爲 Result 或者通用異常類型
統一異常日誌的打印和監控

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

參考資料：

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/IpWtjwcCY7S3irBz34Pw6Q

使用 JSR-305/jetbrain 等註解

用 Optional 處理鏈式調用

使用 Mapstruct

熟練使用線程安全類

保證變更的原子性

使用不可變對象

正確性優先於性能

手動創建線程池

通過 AOP 統一異常處理

處理 Checked Exception

Try catch 線程邏輯

特殊異常的處理

避免 catch Error

通過 SpringBeanFactory 保證初始化順序：

LoadingCache 代替全局 Map

謹慎使用運行時類生成技術

使用 Try With Resource

瞭解常見性能指標 & 瓶頸

使用專業性能測試工具估性能

注意事務註解失效的場景

猜你喜歡