挖掘機技術哪家強？中國山東找藍翔。
但垃圾分類回收哪家強，你知道嗎？
周末，聽聞市長到我們小區檢查垃圾分類的落實情況，足見ZF對這件事非常重視。
其實，不光是生活垃圾，在IT世界中，很多Java程式設計師，每天也在為「垃圾回收」的事情煩惱。
前陣子，接觸到一個黑科技，Zing，讓我突然對JVM有了興趣，為了弄明白，我逼著自己啃了一本厚厚專業書，有些心得體會，跟大家分享一下。
被系統困住的，不僅僅是騎手
網上看到一句話，「毋庸置疑，生活在當下社會，快才是主旋律，快樂往往只是配樂。」
的確，現在這個時代，什麼都要快，打開APP要快，下單要快，送餐要快，掙錢更要快。
前陣子，一篇《外賣騎手，困在系統裡》火爆全網。
騎手困境，演變成社會問題，外賣公司的PR團隊，亮劍接招，說什麼為了保障騎手安全，建議用戶耐心等待5分鐘，甩鍋也是沒誰了。
其實，被算法困住的何止騎手，前幾天，打車的時候，滴滴司機也在抱怨。
師傅說，前一單離目的地還有幾百米距離的時候，滴滴就開始派發新單了。他說，只要上了路，感覺就停不下來，很累。
不是說，不想停，而是停是有代價的，一切皆因算法。
在系統眼裡，只有算法，而在算法眼裡，只有效率，沒有例外，貌似，這一切又皆因客戶體驗。
再回到外賣訂餐這事，為了讓用戶訂餐時體驗更好，背後不知有多少程式設計師和架構師，在不斷的優化應用代碼和系統架構，只為訂餐高峰時，流程順暢，沒有卡頓。
只是，苦逼的程式設計師，用算法把騎手困在系統裡的時候，自己也被性能問題困擾著，好在他們找到了解決問題的神器。
從某種意義上說，「餓了麼」之所以能活下來，除了靠阿里的扶持，還有一個重要的因素，就是他們應用架構中使用了Azul System公司的Zing，才提供了穩定的服務能力，保障了客戶體驗。
據說，美團的一票兄弟，聽聞餓了麼用了神器，也坐不住了。
Zing是什麼？
Azul System，是一家2002成立於美國矽谷的技術公司，100%專注於Java和JVM。
Zing，是Azul公司旗艦產品，一個基於OpenJDK，開箱即用、免調優、GC低時延的JVM。
這個世界，真實的情況是，大多的應用系統註定是平庸的，就好像絕大多數人是普通人一樣。
但像網際網路公司，在交易高峰期，海量並發，或者像券商的交易系統，對於交易延遲的容忍是非常有限的。
以往，遇到問題怎麼辦，修改代碼、架構優化，又或者定期重啟，增加硬體資源。但如果真的定位到是JVM垃圾回收導致的時延和卡頓，上述方案可能都治標不治本。
現在，有了Zing，完全可以換個角度，輕鬆解決。
因為Zing，不是一個普通的JVM，它是一個收費的JVM。
OracleJDK的備胎
除了Zing的高端，Azul公司還有Zulu，一個親民產品線，對開源OpenJDK提供商業支持版本。
如果你在使用開源的OpenJDK，那麼可能面臨兩個主要問題，軟體Bug和安全漏洞。
在JDK 9發布後，Oracle宣布Java開始走持續交付和敏捷開發的路線，每年發布兩個大版本，每六個大版本才會有一個長期支持LTS版本（Long Term Support），只有LTS會獲得3年技術支持，而普通版只有短短半年的生命周期。
比軟體Bug更麻煩的是安全補丁。安全是紅線，隨著開源版本更新速度越來越快，過期了沒有技術支持，你覺得你的系統能頻繁升級嗎？這時，很可能安全團隊的小夥伴，還會發郵件通知你，使用的JDK版本有安全漏洞。
天下沒有免費的午餐，商業公司深諳此道，只是每家的定位不同而已。
要獲得JDK的商業技術支持，要麼乖乖地向Oracle交保護費，要麼選擇Azul這樣的專業廠商，追求技術和服務的綜合性價比。
JVM中的戰鬥機
JVM的垃圾回收，Garbage Collector（簡稱GC），是長久以來固有的問題。
Azul在HotSpot的代碼基礎之上，研發了的Zing，並配置了垃圾回收的專利算法（C4），將GC的暫停時間控制在10ms以內，優化後，甚至可以降到1ms以內。
雖說，HotSpot在JDK 11和12版中，有了ZGC和Redhat的Shenandoah，也達到了相同的目標，但目前效果仍然遠不如Zing的C4。
另外，Zing的ReadyNow功能，可以利用之前JVM運行收集的性能監控數據，引導JVM快速啟動，並迅速達到穩定的高性能水平。
Zing的出現，讓用戶無需了解垃圾回收（GC）的底層調優，就可以讓Java應用享有低延遲，快速預熱和易於監控的功能。
產品的價值也不僅僅局限於此，在大規模應用集群環境中，部署Zing，可以有效提升CPU的資源利用率，縮減集群規模，在解決GC問題的同時，節省運維成本。
有用戶現身說法，「如果沒有Zing，我們可能無法應對交易高峰期出現的GC問題。當GC不再是我們關心的問題時，我們所有的精力都在業務上。」
關於系統運維的反思
通過JVM的學習，我看到了自己工作中的盲點。
之前，做運維，關注系統整體可用性和業務連續性，聚焦在系統架構的高可用。雖然 在應用層實現了負載均衡，但是忽略了單個應用的穩定性。
對於應用的性能問題，在開發支持有限的情況下，更多採取了粗曠的管理方式，不斷擴充資源。
從某種程度上講，硬體擴容、架構改造和應用分拆（微服務），無形中弱化了垃圾回收的性能隱患。
更重要的一點，是行業的交易特性決定的，我們的應用系統，既沒有海量並發的交易量，也沒有苛刻的交易時延要求，因此，對這個GC這個痛點不夠敏感。
日常，更多是因為SQL問題，導致資料庫性能拖拽，進而使得應用線程掛起，或者代碼質量導致的內存洩漏和溢出。另外，監控的顆粒度也沒有這麼細。
當你的ElasticSearch、Kafka和Spark集群出現性能問題，不能穩定輸出的時候，你是否懷疑過這是GC的性能問題，是否有能力通過分析JVM來進行調優。
針對目前Java的使用情況，找了幾個開發團隊的小夥伴做了個調查，目前JDK版本，主要是JDK6-JDK8，個別團隊開始研究JDK11。但他們大都對JVM的技術，並不了解，就是按Java所設計的那樣，只負責程序開發，把內存交給JVM管理。
算法人生
通過Zing的學習，看到了Java和JVM的一些變化。
JVM不再是Java專屬的虛擬機了，只要符合字節碼規範，Groovy和Ruby等很多語言，都能運行在JVM上，開啟了多語言，混合編程的新時代。
根據Oracle最新的策略，Java的版本變更提速了，用戶要麼不斷升級JDK版本，要麼就去購買商業服務。
人生，就好像JVM中的GC算法一樣，經過了很多年，迭代了很多版本，之後才能具備低延遲的能力。
我們每個人，都在生活中都被算法所困，既有外部系統強加的，也有自身認知受限的。
我想，只有不斷學習，更新認知，打破固有的路徑依賴，迭代自己的人生算法，可能才會活得更自由，更快樂。