作者：l拉不拉米 鏈接：https://juejin.cn/post/7031445206152577061 一、前言 公司剛入職了一名中級Java開發，經過一個星期的適應學習，各方面表現還不錯，於是分配了一個小的迭代給新人做。 需求很簡單，把從第三方拉取的數據匹配到自身公司後臺設置的渠道後，聚合到 ...
作者：l拉不拉米
鏈接：https://juejin.cn/post/7031445206152577061
一、前言
公司剛入職了一名中級Java開發，經過一個星期的適應學習，各方面表現還不錯，於是分配了一個小的迭代給新人做。
需求很簡單，把從第三方拉取的數據匹配到自身公司後臺設置的渠道後，聚合到一個列表中，批量入庫。
然而就在匹配的邏輯中，上線後報了個NPE，這是作為一名中級開發不應犯的簡單錯誤，新人被我狠狠的訓了，記生產事故一次。
二、事故重現
偽代碼
說明：偽代碼並非真實線上代碼，只是為了更方便，更形象的重現事故現場而編寫的；真實的業務場景往往更加複雜，NPE的漏洞隱藏在更深處，不易code view出來，也不易測試出來；生產環境NPE是較常見的異常，希望大家不要糾結為什麼測試沒測出來，關鍵還是通過這樣一個案例瞭解NPE的原因和解決方案。
// 後臺設置的渠道
String channelNo = channelDao.getOne().getChannelNo();
// 第三方拉取的數據
List<ThirdData> thirdDataList = httpClientUtils.getThirdDatas(DateUtils.today());
// 匹配過濾
thirdDataList.stream().filter(o ->channelNo.equals(o.getChannelNo())).collect(Collectors.toList());
// 批量入庫
thirdDataDao.saveAll(thirdDataList);
分析與解決
有經驗、技術扎實的同學看到這裡應該或多或少能發現問題了。其實啊，這四段代碼是作者精心設計的，可謂是卧龍鳳雛
