jdk10.0.1這個版本的jdk已經適用于大部分的編程環境，作為編程人員必須的環境，支持多個ide，最為標準的開發模式，讓你可以更加方便的體驗到開發軟件的便捷之處，只需要根據小編給出的安裝方式操作即可！

java se development kit 10介紹

JDK 10 是最新的java 10標準開發環境，抱恨了jre10和java10開發工具，是Windows系統常用的組件，附上詳細的安裝教程，有需要的就下載吧。

JDK 10 的新改進有哪些？

JDK 10 的主要功能包括： 

一個局部變量類型推斷，通過增強語言特性將類型推斷擴展到局部變量，目的是減少與編碼相關的“儀式”，同時保持對靜態類型的安全承諾。 

一個干凈的垃圾收集器接口，用來改善垃圾收集器源代碼之間的隔離效果，這樣可以為HotSpot 虛擬機中的內部垃圾收集代碼提供更好的模塊化功能，也可以更容易向 HotSpot 添加新的垃圾收集器。 

并行、完整的 G1 垃圾收集器，通過實現并行性來改善最壞情況下的延遲問題。 

啟用 HotSpot 將對象堆分配給用戶指定的備用內存設備（如 NVDIMM 內存模塊），這個特性也側面預示了未來的系統可能會采用異構的內存架構。 

JDK10 包含 12 個JEP (改善提議）：

【286】局部變量類型推斷 ：對于開發者來說，這是 JDK10 唯一的真正特性。它向 Java 中引入在其他語言中很常見的  var   ，比如 JavaScript 。只要編譯器可以推斷此種類型，你不再需要專門聲明一個局部變量的類型。一個簡單的例子是：

var x = new ArrayList();

這就消除了我們之前必須執行的 ArrayList 類型定義的重復。我鼓勵你們去讀 JEP ，因為上面有一些關于這個句法是否能用的規則。

有趣的是，需要注意 var 不能成為一個關鍵字，而是一個保留字。這意味著你仍然可以使用 var 作為一個變量，方法或包名，但是現在（盡管我確定你絕不會）你不能再有一個類被調用。

[310]應用類數據共享(CDS) ：CDS 在 JDK5 時被引進以改善 JVM 啟動的表現，同時減少當多個虛擬機在同一個物理或虛擬的機器上運行時的資源占用。

JDK10 將擴展 CDS 到允許內部系統的類加載器、內部平臺的類加載器和自定義類加載器來加載獲得的類。之前，CDS 的使用僅僅限制在了 bootstrap 的類加載器。

[314]額外的 Unicode 語言標簽擴展：這將改善 java.util.Locale 類和相關的 API 以實現額外 BCP 47 語言標簽的 Unicode 擴展。尤其是，貨幣類型，一周的第一天，區域覆蓋和時區等標簽現在將被支持。

[322]基于時間的版本控制：正如我在之前的博客中所討論的，我們的 JDK 版本字符串格式幾乎與 JDK 版本一樣多。有幸的是，這是最后需要使用到的，我們可以堅持用它。這種格式使用起來很像 JDK9 中介紹的提供一個更加語義的形式。有一件困擾我的事是包含了一個 INTERIM 元素，正如 JEP 提議中所說，“永遠是0”。好吧，如果永遠是0，那它有什么意義呢？他們說這是為未來使用做保留，但我仍不是很贊同。我認為，這有些冗余繁雜。

這也消除了在 JDK9 中有過的相當奇怪的情形。第一次更新是 JDK 9.0.1 , 非常符合邏輯。第二次更新是 JDK 9.0.4 ，不合邏輯。原因是，在 JDK9 的版本計數模式下，需要留下空白以便應急或不在預期安排的更新使用。但既然沒有更新是必須的，為什么不簡單稱之為 JDK 9.0.2 呢？

[319]根證書：在 JDK 中將提供一套默認的 CA 根證書。關鍵的安全部件，如 TLS ，在 OpenJDK 構建中將默認有效。這是 oracle 正在努力確保 OpenJDK 二進制和 Oracle JDK 二進制功能上一樣的工作的一部分，是一項有用的補充內容。

[307] 并行全垃圾回收器 G1 : G1 是設計來作為一種低延時的垃圾回收器（但是如果它跟不上舊的堆碎片產生的提升速率的話，將仍然采用完整壓縮集合）。在 JDK9 之前，默認的收集器是并行，吞吐，收集器。為了減少在使用默認的收集器的應用性能配置文件的差異，G1 現在有一個并行完整收集機制。

[313]移除 Native-Header 自動生成工具：Java9 開始了一些對 JDK 的家務管理，這項特性是對它的延續。當編譯 JNI 代碼時，已不再需要單獨的工具來生成頭文件，因為這可以通過 javac 完成。在未來的某一時刻，JNI 將會被 Panama 項目的結果取代，但是何時發生還不清楚。

[304]垃圾回收器接口: 這不是讓開發者用來控制垃圾回收的接口；而是一個在 JVM 源代碼中的允許另外的垃圾回收器快速方便的集成的接口。

[312]線程-局部變量管控：這是在 JVM 內部相當低級別的更改，現在將允許在不運行全局虛擬機安全點的情況下實現線程回調。這將使得停止單個線程變得可能和便宜，而不是只能啟用或停止所有線程。

[316]在備用存儲裝置上的堆分配：硬件技術在持續進化，現在可以使用與傳統 DRAM 具有相同接口和類似性能特點的非易失性 RAM 。這項 JEP 將使得 JVM 能夠使用適用于不同類型的存儲機制的堆。

[317] 試驗性的基于 Java 的 JIT 編譯器：最近宣布的 Metropolis 項目，提議用 Java 重寫大部分 JVM 。乍一想，覺得很奇怪。如果 JVM 是用 Java 編寫的，那么是否需要一個 JVM 來運行 JVM ？ 相應的，這導致了一個很好的鏡像類比。 現實情況是，使用 Java 編寫 JVM 并不意味著必須將其編譯為字節碼，你可以使用 AOT 編譯，然后在運行時編譯代碼以提高性能。

這項 JEP 將 Graal 編譯器研究項目引入到 JDK 中。并給將 Metropolis 項目成為現實，使 JVM 性能與當前 C++ 所寫版本匹敵（或有幸超越）提供基礎。

[296]: 合并 JDK 多個代碼倉庫到一個單獨的儲存庫中：在 JDK9 中，有 8 個倉庫： root、corba、hotspot、jaxp、jaxws、jdk、langtools 和 nashorn 。在 JDK10 中這些將被合并為一個，使得跨相互依賴的變更集的存儲庫運行 atomic commit （原子提交）成為可能。

jdk10 安裝教程：

點擊安裝包安裝，需要注意的是，選擇安裝目錄，不要選到C盤。推薦使用像我這種目錄風格，比如

D:JDK10

以便多JDK共存。

同時取消勾選JRE安裝，因為JDK從來都是包含JRE的，一般沒有必要再獨立安裝一個JRE浪費硬盤。

配置環境變量

進入電腦的系統環境變量設置頁面，win10系統直接在左下角搜索&環境變量&即可

在系統環境變量中新建一個JAVA_HOME環境變量，目錄選擇JDK10的安裝目錄如

D:JDK10

保存

在Path變量中，增加一個

%JAVA_HOME%bin

變量，記得讓這個變量處于第一個位置，這樣可以讓它優先級最高，防止安裝在C盤的其它JRE和它沖突。

進入cmd命令提示符，win10系統可以在左下角搜索cmd，回車進入。

輸入

java -version

可以查看當前JAVA版本

輸入

where java

可以查看java命令來源的目錄，如果配置正確的話，JDK10的安裝目錄，應該是第一行輸出。我這里第二個是C盤安裝了一個JRE。如果在PATH變量中，

%JAVA_HOME%bin

的位置在最后了，可能就會被這個JRE覆蓋，導致輸出版本不是自己預期的。

DK10中包含許多對JVM的優化：

將JDK多存儲庫合并為單存儲庫

并行Full GC 的G1

垃圾回收接口

應用數據共享

線程局部管控

基于實驗JAVA 的JIT 編譯器

備用內存設備上分配堆內存