Flink的常見異常眾多，不可能面面俱到，所以想到哪兒寫到哪兒，有漏掉的之後再補充。
這不是個顯式錯誤，但是JDK版本過低很有可能會導致Flink作業出現各種莫名其妙的問題，因此在生產環境中建議采用JDK 8的較高update（我們使用的是181）。
該信息不甚準確，因為絕大多數情況下都不是JAR包本身有毛病，而是在作業提交過程中出現異常退出了。因此需要查看本次提交產生的客戶端日誌（默認位於$FLINK_HOME/logs目錄下），再根據其中的信息定位並解決問題。
壹般都是因為用戶依賴第三方包的版本與Flink框架依賴的版本有沖突導致。如果是采用Maven做項目管理的話，可參照我之前寫的 這篇文章 來解決沖突。
就是字面意思，YARN集群內沒有足夠的資源啟動Flink作業。檢查壹下當前YARN集群的狀態、正在運行的YARN App以及Flink作業所處的隊列，釋放壹些資源或者加入新的資源。
slot分配請求超時，是因為TaskManager申請資源時無法正常獲得，按照上壹條的思路檢查即可。
TaskManager的Container因為使用資源超限被kill掉了。首先需要保證每個slot分配到的內存量足夠，特殊情況下可以手動配置SlotSharingGroup來減少單個slot中***享Task的數量。如果資源沒問題，那麽多半就是程序內部發生了內存泄露。建議仔細查看TaskManager日誌，並按處理JVM OOM問題的常規操作來排查。
TaskManager心跳超時。有可能是TaskManager已經失敗，如果沒有失敗，那麽有可能是因為網絡不好導致JobManager沒能收到心跳信號，或者TaskManager忙於GC，無法發送心跳信號。JobManager會重啟心跳超時的TaskManager，如果頻繁出現此異常，應該通過日誌進壹步定位問題所在。
Flink on YARN的其他問題，還可以參考 這篇 ，非常有幫助。
該異常幾乎都是由於程序業務邏輯有誤，或者數據流裏存在未處理好的臟數據導致的，繼續向下追溯異常棧壹般就可以看到具體的出錯原因，比較常見的如POJO內有空字段，或者抽取事件時間的時間戳為null等。
很多童鞋拿著這兩條異常信息來求助，但實際上它們只是表示BufferPool、MemoryManager這些Flink運行時組件被銷毀，亦即作業已經失敗。具體的原因多種多樣，根據經驗，壹般是上壹條描述的情況居多（即Could not forward element to next operator錯誤會伴隨出現），其次是JDK版本問題。具體情況還是要根據TaskManager日誌具體分析。
Akka超時導致，壹般有兩種原因：壹是集群負載比較大或者網絡比較擁塞，二是業務邏輯同步調用耗時的外部服務。如果負載或網絡問題無法徹底緩解，需考慮調大 akka.ask.timeout 參數的值（默認只有10秒）；另外，調用外部服務時盡量異步操作（Async I/O）。
這個異常我們應該都不陌生，首先檢查系統 ulimit -n 的文件描述符限制，再註意檢查程序內是否有資源（如各種連接池的連接）未及時釋放。值得註意的是，Flink使用RocksDB狀態後端也有可能會拋出這個異常，此時需修改flink-conf.yaml中的 state.backend.rocksdb.files.open 參數，如果不限制，可以改為-1。
關於文件描述符的壹些有趣知識，可以參見之前我寫的 這壹篇 。
在Flink內使用Java Lambda表達式時，由於類型擦除造成的副作用（詳情見 這篇文章 ），註意調用returns()方法指定被擦除的類型。
在當前檢查點還未做完時，收到了更新的檢查點的barrier，表示當前檢查點不再需要而被取消掉，壹般不需要特殊處理。
首先應檢查 CheckpointConfig.setCheckpointTimeout() 方法設定的檢查點超時，如果設的太短，適當改長壹點。另外就是考慮發生了反壓或數據傾斜，或者barrier對齊太慢。具體思路不再贅述，看官可以參考 這篇文章 ，非常詳細。
我們知道Flink的狀態是按key組織並保存的，如果程序邏輯內改了keyBy()邏輯或者key的序列化邏輯，就會導致檢查點/保存點的數據無法正確恢復。所以如果必須要改key相關的東西，就棄用之前的狀態數據吧。
在1.9之前的Flink版本中，如果我們使用RocksDB狀態後端，並且更改了自用MapState的schema，恢復作業時會拋出此異常，表示不支持更改schema。這個問題已經在 FLINK-11947 解決，升級版本即可。
就醬吧，民那晚安（不是