公司是服務顧客的，而顧客可不管你用什麼版本，只需要好用穩定就好，所以公司首要的目標是穩定，穩定勝於一切，至於新技術，都要排在穩定後面，除非現有的技術解決不了或基本穩定的同時可以帶來其他好處的

關於這個問題我個人認為有兩個原因：

Oracle 對2019 年 1 月以後釋出的 Java SE 8 公開更新需要獲取商用許可證，不向沒有商用許可證的業務、商用或生產用途提供，在2019年1月前釋出的Java 8 更新版本則不受影響。

Java 8 目前的效能很穩定，而且很多專案都是基於Java 8開發的，一旦升級Java 新版本，很有可能出現一些意外的風險，很多公司並不願意承擔這些風險。

Java 8應對絕大部分場景的開發，已經足夠了；Java 新版本帶來的很多新特性，對於企業來說並不重要。

但自 Java SE 9 以後，Oracle 還提供了 OpenJDK 版本，可免費用於商業用途，並且還有其他服務商提供的免費 OpenJDK 版本可供選擇，如 AdoptOpenJDK、Azul、IBM、Red Hat、Linux distros 等。所以如果想繼續免費使用 Java 8，你可以：

不再更新，繼續使用當前 Oracle JDK 8版本；

使用其他服務商（如 AdoptOpenJDK、Azul、IBM、Red Hat、Linux distros 等）的 Java SE 8 / OpenJDK 8 二進位制分發版。

對於新的專案更高版本的jdk時沒有問題的，如果開發專案選jdk當然會選高版本（雖然說高版本有不穩定因素）。但對於已經完成的專案是否需要升級jdk我覺得是有待商榷的，jdk升了程式碼要不要重寫？架構要不要重構？這些只是技術方面的問題，更大的阻礙在領導那邊，只有當你切切實實能拿出收益的時候這個事情才能推行下去。比如6到8效能是有很大進步的，synchronized進行了最佳化引入了偏向鎖輕量級鎖適應性自選，HashMap用尾遞迴解決了環形連結串列，ConcurrentHashMap的鎖粒度到了節點，等等很多你甚至不用改程式碼就能得到的效能提升，記憶體方面可以使用G1了(非預設需要在jvm引數中指定)在某些業務下對記憶體的利用更加充分，上述的變化帶的是使用者體驗的提升是硬體成本的減少，沒有幾個真的懂且想做實事的領導會拒絕。反觀11帶來的收益更多的是針對開發的，型別推斷用的多爽，我希望後續還可以根據類自動生成介面呢，但語法糖這種東西只會讓我們爽，你的專案經理看到的確是沒有明顯的收益和帶來的穩定性的挑戰。

總結：目前成熟的公司基本上都有一套寫好的基線版本java程式碼，有自己的規範和約束，換高版本就會涉及到一些升級相容，未知bug修改等工作量去做。對於公司來說，這個研發成本是不可控的，畢竟公司還是以盈利為目的。

確實如題主所說，目前大部分公司依舊在用jdk1.8的版本，我在面試的時候通常情況下都會問一下候選人之前公司線上使用的jdk版本，目前還沒有遇到使用1.8以上的版本，所以我們通常在面試交流的時候基本上都會基於1.8版本～

那麼問題來了，JDK14已經於2020年3月17日如期釋出，為什麼大家還在普遍使用JDK8的版本？

大家可以去oracle官網看看oracle公司對各個版本的JDK版本支援路線圖，文章地址如下：

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

各版本支援如下表：

可以看到自JDK8以後，只有JDK11是LTS（Long Term Support）的，其他9、10、12、13、14以及還未釋出的15都是non-LTS的。

那麼對於使用JDK的公司來說，只有JDK8和JDK11可以選擇，你官方都說不是長期演進版的，我們還用幹嘛？

oracle已經告訴我們了要麼使用JDK8，要麼使用JDK11，那麼到底是使用JDK8還是使用JDK11呢？

說到JDK8的新特性大家都如數家珍，什麼stream流操作、lambda表示式、HashMap的最佳化、ConcurrentHashMap的鎖最佳化、Synchronized的鎖升級最佳化、Optional等等，使用的時候也是輕車熟路，網上相關文章也是數不勝數，面試的時候也是必問的。

JDK11呢？似乎面試時候大家也不問，大家用的也不多，即使去學習了，去程式碼實操了，但是過段時間也忘了，這就意味著有開發成本和試錯成本，俗話就是有坑需要踩。

不是說JDK11有坑，是咱們用JDK11開發有坑，也許你用了其中的一個新特性，覺得很牛逼，然後上線了，然後執行一段時間了就不知不覺的出bug了，然後你還不知道問題出在哪，想想是不是很恐怖？

老專案不用多說，肯定是不會輕易升級JDK版本的，公司不可能給你提供這個資源來升級JDK版本，除非說JDK8有bug，然而JDK8很穩定，效能也很好。網上有關於JDK8和JDK11的效能測試相關文章，大家可以搜一搜。

那新專案用JDK11可不可以呢？用過JDK11開發專案的同學應該會有了解，他是無法向下相容的。也就是如果你決定使用JDK11，意味著你需要單獨的一套環境來執行你這個專案，之前的運維環境你通通都不行，然後你還要考慮更多的是你專案使用的其他第三方依賴包是否是基於JDK11開發的？所有的一切你都得小心點，你需要能夠徹底的掌控它～

無論怎麼說，最終我們都會慢慢轉向JDK11甚至更高的版本！

有的同學會說JDK8不收費，JDK11需要商業使用許可證，意味著收費。其實我覺得這點不用擔心，開源的力量足以讓社群版本高可用。除非你需要oracle公司的商業支援。

也許有一天JDK8會成為歷史，就像現在大家看JDK6一樣：“如果有公司還在使用JDK6，你會感覺這個公司技術真low”。

我現在唯一能期待的是，但願那個時候我們都還在Coding，僅此而已～

我認為最主要的原因是大多數公司追求的是穩定。

Java是一門企業級程式語言，很多公司的業務使用Java開發，大多數公司當然是要追求穩定，老的業務使用JDK8開發，新的業務當然也跟著使用JDK8開發。

最近幾年Java版本升級速度比較快而且版本支援的時間比較短，企業追求的是穩定不可能跟著JDK發行的版本去更新。而且更換JDK版本又有一定的風險，更換帶來的收益又不是很大所以很多公司都是不願意升級新版本的。僅僅升級JDK，又沒有使用新的語法意義不大。

Java8的效能穩定能夠滿足企業的業務需求，在追求專案穩定的企業沒有必要去更換新的JDK。

分享駭客技術，物聯網、GO、Python、Kotlin、Android、Java程式設計知識，科技資訊等

公司最最重要的就是商業成本，絕大多數公司的業務對支援海量資料，高併發等並無實際需求，應用最新框架的動機也不迫切。

儘可能在上一個版本基礎上完成業務需求是最重要的（業務培訓的成本也最小），而一個業務系統的生命週期也是有好幾年的，這直接導致JDK的版本維持在JDK8了，早幾年的時候網上問的是為什麼還在用JDK1.6。

最新版本的springboot，仍然是採用jdk8編譯的，作為最流行的框架，使用同版本jdk當然穩定性是最好的，有次也可以看出，求穩是全世界IT界的共性

軟體工程專案，需要考慮穩定性的問題。這一方面是團隊內部技術儲備的穩定性，另一方面是研發環境工具軟體的穩定性。這也是軟體專案往往不會去嘗試較新技術的原因，因為新技術往往會有許多隱藏的，未知的，沒有被發現的bug存在。

很多新特性，由於使用的人少，所以不易被發覺。如果為了追求新技術，而去貿然的使用最新的版本的話，則很有可能把專案置於不穩定的基礎之下，這是沒有經驗的專案經理才會去做的蠢事。這就有點像是蓋樓房，如果根基不穩的話，那上層建築是會很危險的。

其次是專案團隊。在軟體專案研發初期，選擇研發工具的時候，必須要在專案團隊中統一各種軟體工具的版本。否則版本混亂帶來的風險，會導致專案團隊暴露在極大的風險，極大的不穩定當中，很難進行溝通，甚至是溝通失效，專案團隊的學習曲線也會變長。

所以，現代化的軟體工程專案管理，一定要考慮專案環境的穩定性。對各種工具軟體，必須規範其版本號，絕對不允許出現不同研發人員，所使用的版本不一致的情況發生。如果出於商業目的考慮，必須要去使用新版本中的新技術的話。那就需要在專案團隊的區域性範圍內，先進行完整詳細的測試，充分保證新技術不會給專案帶來問題之後，才能讓團隊成員全部升級到統一的一個新版本。這就是很多公司仍然選擇適應JDK8的原因。

其實道理很簡單，就是升級成本比較大，一般公司承擔不起。

大家在企業或者機關單位工作的時候，常常會遇到一個甩鍋的問題，一件事情本來和你沒關係，但是一旦經過了你的手，那麼萬一出了問題就和你扯上關係了。舉個我自己的例子，之前某次我看單位電腦流氓軟體太多了，順手優化了一下，這下好了，三番兩頭有人問我是不是動電腦了，電腦的問題全部來找我，簡直是煩不勝煩。明明電腦就是老電腦，裡面充滿了各種自啟，本來就卡的不行，我做的事情僅僅是解除安裝了兩個多餘的防毒軟體而已。

在說回到升級JDK版本這回事，要知道公司裡面的專案一般都大量利用了各種第三方類庫，而且經過了很多程式設計師的開發和修改，因此牽扯的東西非常多。雖然現在JDK升級已經平滑了很多，但是如果直接升級仍然會出現很多問題，而這些問題在公司中都是非常致命的，麻煩程度比我前面說的最佳化電腦要高上幾百倍。畢竟現在很多公司還是唯KPI，你為公司更新軟體版本不會多掙錢，出了問題不僅要修bug，問題過大還要倒扣獎金，我相信凡是一個腦子正常的程式設計師都不會這麼幹的。

所以，現在很多公司裡面的專案都是能用就用，除非徹底用不了了才開始研究如何升級。如果要解決這方面的問題，還是要從公司的制度下手，設立專門的獎金，鼓勵程式設計師及時升級版本，並且有完善的工作流程，在升級專案途中遇到問題可以及時回溯版本，追蹤問題源頭，可惜這一點整個世界沒幾家公司可以做到。

這裡還要反對一些朋友的觀點——JDK8夠用。如果這句話成立的話，用同樣的理由我可以說JDK5/6/7都夠用。但是假如真的夠用的話，Oracle和JAVA社群為什麼還要每年費勁更新新版本呢，像原來那樣一個版本不更新不好嗎？其實情況是一些低端程式設計師不願意學習，停留在自己的舒適區裡沾沾自喜，對於自己沒學過沒用過的特性就說沒用。Java 9的模組化、JShell、HTTP/2 、Java 11的超低延遲的ZGC等等，都是非常關鍵的特性，對專案有很多幫助。

實際上現在JAVA更新頻繁，每個版本都加入了很多新的特性，積攢幾個版本下來就是極大的進步。當然作為企業不必無腦追新，有些JAVA版本屬於短期版本，支援週期只有幾個月，但是像JAVA 11這種長期支援版，企業完全可以考慮升級。比較符合實踐的做法就是對於舊專案，及時修復那些關鍵的安全問題，一般的版本更新可以不做，以專案穩定執行為優先；而對於新開發的專案，推薦基於最新的長期支援版開發，以利用新版本的新功能優先。

為什麼大部分專案還不使用jdk8以上版本。總結一下，就是Java 9+裡面，各種奇怪的改變+業界長久積累的庫中的瞎JB用法導致了大部分專案被迫停在Java 8上。我強烈建議把題目改成「為什麼還有那麼多人被迫使用Java 8」，因為，這真的是客觀原因啊。

我舉幾個例子讓你們看看遷Java 9/11這件事情有多蛋疼，算是給想遷移的你們提前打個預防針。

Java 9之前，Java的版本號用的是這個標準，也就是我們常見的1.8.0_213這種字串。 Java 9之後，大家一拍大腿，反正已經做了這麼多改變，不差這一個！來人啊！給我把這個版本號字串換掉！於是有了JEP223，一個山寨版的語義化版本號，從此以後，版本號大概長這個樣子：9.0.0.4。平心而論，這個變更是非常必要的，但是一眾依賴以前的版本號字串的庫就都哭了……誰能想到你丫的連這種東西都變啊。

（據說當年還有人提議以後Java的版本號跟業界保持一致，用18.1/19.1之類的年份+次序命名 ，後來就沒聲音了，應該是被打死了。）

那些廣為人知的大庫還好說，改的還算及時，一些小作坊生產的三無庫就慘了，一呼叫就給你丟個Illegal version number 9.0.0.4出來， 還找不到人修，來來來你說咋辦？

Java 8之前對反射沒有限制，只要setAccessible(true) ，你連JVM的底褲都可以掀掉。我們都知道，一旦給使用者自由，使用者就會瞎JB用。大家都知道JVM初始化的時候傳進來的環境變數是不可變的，存在ProcessEnvironment的一個不可變Map裡。但是沒關係，我有反射啊……

其他的例子還包括，透過反射呼叫各種私有的API……在你升級之前，你永遠不知道有多少地方在用這種鬼鬼祟祟的操作……升級就好像你面前的一條康莊大道，你開開心心地踏上去準備走，咚！一個地雷炸了！piaji！你掉坑裡了！二十米的路你走了三個月！黑著臉從坑裡爬出來，瞅瞅前面……這特麼還有多少個地雷在等著我啊……在爆炸之前你永遠不知道到底有多少庫在用反射偷偷摸摸調私有API，我管它叫薛定諤的反射。

這都是業界的庫裡的騷操作（其實我們的程式碼裡也有……捂臉），Java 9對反射添加了限制。JDK團隊最初計劃在Java 9中全面限制反射，但最後因為影響太大沒能實行……

還有最常用的一個操作叫做defineClass，用來把魔改後的位元組碼注入ClassLoader。ClassLoader的這個方法是protected的，沒關係，我們有反射啊……另外一些小夥伴直接用反射呼叫Unsafe.defineClass——看名字你就知道有多不安全，Java 11之後這個方法直接被幹掉了。

能用到這些方法的庫通常都是大廠生產的有售後的庫，所以通常都能得到很好的解決。但是緊接著問題就來了——你把一個庫從2011年的版本直接升到了2018年的版本，你心裡慌不慌？

更別提有些小作坊的庫偷偷摸摸地從褲襠裡掏出來一個Unsafe.defineClass跟你哭喪著臉說，哥，這個方法我找不到了，咋辦……

在升Java 9成功之後，懷抱著升級成功的竊喜，我們又趁熱打鐵想升Java 10。然後碰到了IDEA的一個bug：IDEA錯誤地理解了一個還未生效的草案JEP182，編譯器給出了不正確的結果，我花了一上午時間除錯IDEA的原始碼才發現是IDEA的鍋。IDEA尚且如此，其他專案碰到相容性問題，真的只是時間問題。

業界的很多工具不支援Java 9，最廣為人知的應該是FindBugs了。還好，它還算後繼有人，SpotBugs挑起了它的大梁，那些小作坊庫可就慘了，過去的十年是Java生態系統迅猛發展的十年，你的專案只要沾到一點“在自己的程式碼裡瞎JB使用Java 8/斷言自己使用的是Java 8”的庫，可能就要花上幾天時間去除錯、去嘗試解決。

最後，最重要的一點是，我們的程式碼是有嚴格的自動化測試覆蓋的，所以我們在升級之後能非常有底氣地說我們升級成功了！對於沒有測試覆蓋的祖傳程式碼，你升級完事，跑一下，似乎沒問題，但是真的沒問題麼？去問老天爺吧……沒有完善的測試覆蓋的專案請勿輕易嘗試。

其實升級不是什麼非常困難的事情，主要是費時費力，收益可能卻沒有那麼明顯。對於一個成熟的公司來說，程式碼只是輔助業務的手段，而非目的。如果沒有十分的利益保證，別說升級，連bug都是可以不修的。就醬。

只要你使用的庫裡有一個不支援java11，你就沒法升級啊。或者有替代的庫，但你得改程式碼啊，一堆祖傳程式碼沒人想碰，或者說根本不敢碰，就算能編譯過，也能啟動，你敢保證行為沒變化嗎？這怎麼搞

你看redhat和amazon都維護自己的openjdk8 build了，就知道大廠怎麼看這事了。還有一大堆人停留在6甚至4呢，你問為啥有人還在用8？

不是不想升，而是有些時候不能升啊！

Java 14都快出來了，為什麼還有那麼多人執著於Java 8？

從Java 9開始，Java版本的釋出就讓人眼花繚亂了。

每隔6個月，都會冒出一個新版本出來，Java 10 , Java 11, Java 12, Java 13， 到2020年3月份，Java 14就要來了。

說實話，這種頻繁的釋出有點兒讓人審美疲勞，每次我看到介紹Java新版本，新特性的文章也沒興趣點開看了。

在這麼多的版本中，只有Java 8, Java 11 和未來的Java 17 是長期支援版本（LTS），Oracle會支援3年，其他的只會支援6個月，新版本一出，就放棄老版本的技術支援。

Java 14都快出來了，為什麼還有那麼多人執著於Java 8？

這種快速的釋出有好處嗎？

有 ！ 小步快跑一直是我們軟體開發的利器，採用迭代的方式，每次釋出一部分功能，推向開發人員去驗證，典型的敏捷思路。

但是這種好處更有利於JDK的開發者，對使用Java的個人和公司來說，想要跟上每六個月就要升級的步伐，實在是太難了。JDK是個非常核心的基礎設施， 除了安全漏洞，誰沒事去升級生產環境的JDK啊？出了問題誰負責？

所以，按道理講大家都會去找那些LTS的版本來升級，例如Java 11， 但是事實證明大部分人還在固守Java 8 :

Java 14都快出來了，為什麼還有那麼多人執著於Java 8？

這個調查顯示，使用Java 8的公司和程式設計師高達80%， 這是為什麼呢？大家為什麼不升級到Java 11呢？

我個人覺得主要原因是對開發有利的重大特性升級很少，吸引力不夠。

在過去的十幾年中，Java相繼引入的泛型、註解、NIO、函數語言程式設計等核心功能，極大地影響了應用程式開發的方式，你能想象現在的Java中沒有註解會是什麼樣子嗎？

這幾年的Java版本中，就缺乏這種重大功能的升級了，我把我有點印象的功能升級列一下：

Java 14都快出來了，為什麼還有那麼多人執著於Java 8？

注意黑體的這幾項， Java 9引入了模組化系統，這是個看起來很美的特性，可是對程式設計師來說，這是一個破壞性的更新，因為JDK做了模組化，但是很多第三方庫沒有做模組化， 如果想讓自己的專案也模組化，很有可能是一次不斷填坑的經歷，尤其在使用第三方庫的時候。

Java 11的ZGC是個有吸引力的特性，它的設計目標是：支援TB級記憶體容量，GC暫停時間低（<10ms），對整個程式吞吐量的影響小於15%，確實挺讓人激動的！如果真的實現了，程式設計師就可以可勁兒造物件，而不用考慮GC了，可惜這仍然是個實驗性質的版本。

至於區域性變數型別推導，也只是方便了變數的宣告而已。

一個JDK的版本如果想被廣泛採用，一定得能提升開發效率（如泛型、註解），帶來變革，這樣才有吸引力， 如果給程式設計師們帶來了麻煩， 大家就會用腳投票了。

Java 8 已經發布好多年，我估計再用好多年年不成問題。

從技術的角度來說，使用新版本可以提升效率，但是決定一個軟體的使用穩定程度有時候是另外一個層面的問題。我們的顧客是軟體的使用方，而顧客需求有時候是穩定大於一切，所以公司領導在決策時候穩定是第一考慮要素，至於新技術，都要排在穩定後面。但是專案內部是允許進行一些新技術的嘗試，對內鼓勵專案組成員新技術拓展，對外目標客戶以穩定為主，當客戶需要嘗試一部新技術時候就可以開始一些推薦。

新功能雞肋

升級成本高

有的公司的產品迭代速度甚至都趕不上jdk的迭代速度，或者是專案特別老，現在用jdk6的公司比比皆是，升級之後萬一不相容線上各種報錯，維護成本太高，所以投入大量維護成本就是為了一個“新特性”？

惰性

人都有惰性，jdk可不是你一個人說了算的，你某天一拍腦門說我們得升級jdk到最新版本，當你說完這句話之後你可以注意下你旁邊的同事，臉有沒有耷拉到地上，有的話幫他撿起來！然後再給現場運維大哥打個電話，聽聽從聽筒裡傳出來的優美的中國話。