あなたが暗記した「8部構成のエッセイ」は古いかもしれません。

データから大規模モデルのアプリケーションまで、開発のヒントを共有する杭州元創会議が 11 月 25 日に開催されました。

1. Char[] は String では使用されなくなりました

JDK9 より前では、String は char 配列 (char[]) を通じて文字データを内部的に格納していました。しかし、JDK9 以降、 String の実装はバイト配列 (byte[])を使用するように内部的に変更されました。これを行う主な理由は、メモリ領域を節約することです。これは、多数のラテン系文字 (英語、数字、一般的な句読点など) の場合、バイト配列ストレージを使用すると、char 配列を使用する場合よりも半分の領域を節約できるためです。

同時に、coder という名前のバイト型フィールドも String クラス内に導入されます。このフィールドは、バイト配列に格納されているデータの文字エンコーディングを識別するために使用されます。新しい String クラスの実装では、ISO-8859-1 (1 文字が 1 バイトを占有する) と UTF-16 (1 文字が 2 バイトを占有する) の 2 つの文字エンコーディングが可能です。ISO-8859-1 でエンコードされた文字列の場合、コーダー値は 0 であり、UTF-16 でエンコードされた文字列の場合、コーダー値は 1 です。このように、coder フィールドの値を確認することで、バイト配列に格納されたデータをどのようなエンコード方式で処理すべきかを知ることができ、文字エンコードの違いによる処理エラーを回避できます。

2. スイッチでサポートされる型は、基本型と String に限定されなくなりました。

この話をする前に、まず「パターンマッチング」とは何かを理解する必要があります。パターンマッチングとは、特定の値が特定のパターンに一致するかどうかを確認し、その結果に基づいて対応するコードを実行するために使用される言語機能です。Scala および Haskell におけるパターンマッチングは、 Java では、パターンマッチングの概念が JDK14 以降に導入されました。

簡単に言うと、パターンマッチングを使用すると、変数または値の型が、設定された特定のルール (パターン) に一致するかどうかを確認でき、一致する場合または一致しない場合に、特定の操作を実行できます。たとえば、パターンマッチングにより、次の操作を指定できます (JDK14)。

Object obj = "hello";
    if (obj instanceof String str) {
        System.out.println(str.length());
    }

この例では、「文字列 str」がパターンとなっており、型チェック（instanceof）と下方変換（変数 str への代入）が同時に完了するため、コードが簡潔になります。JDK17 では、スイッチもこの機能をサポートします。

Object obj = 10L;
    switch (obj) {
        case String str -> System.out.println("str: " + str);
        case Integer intNum -> System.out.println("int: " + intNum);
        case Long longNum -> System.out.println("long: " + longNum);
        default -> throw new IllegalStateException("Unexpected value");
    }

ただし、現在のパターンマッチングは、主に型チェック時の自動変換に使用されています (少し大雑把ですが)。他の言語では、パターンマッチングは、マッチング中に複雑なデータ構造から値を抽出するなど、さまざまな機能も実装できます。

val list = List(1, 2, 3)
list match {
  case head :: tail => println(s"head: $head, tail: $tail")
  case Nil => println("empty list")
}

この例の head::tail は、キューの先頭と末尾をそれぞれ head オブジェクトと tail オブジェクトに入れて、次のステップを実行するパターンです。

3. 同期バイアスロックは放棄されました。

まず、バイアスされたロックとは何かを確認しましょう。バイアスロックは、Java の synchronized キーワードの最適化方法です。基本的な考え方は、同じスレッドによる繰り返しアクセスにはロックが必要ないということです。主な目標は、競合のないデータの同期を排除し、実行時のパフォーマンスを向上させることです。実際の実行中に、スレッドがロックを取得すると、ロックはバイアスモードになり、スレッド ID が記録されます。スレッドが再度ロックを要求するときは、同期操作は必要ないため、ロックアプリケーションの問題の多くが排除されます。 . 動作します。

ただし、実際の状況では、バイアスされたロックが必ずしも期待されるパフォーマンス上の利点をもたらすとは限りません。それどころか、場合によっては (マルチコアプロセッサ環境)、バイアスされたロックの取り消しはグローバルセーフティポイント(セーフポイント、仮想ポイント)に入る必要があります。マシンはすべてのスレッドの実行を一時停止します)。これにより、比較的長い一時停止時間が発生します。

バイアスされたロックのアイデアは良いものですが、 JVM の複雑さが増し、すべてのアプリケーションのパフォーマンスが向上するわけではありません。したがって、JDK15 ではバイアスロックはデフォルトでオフになっていますが、JDK18 ではバイアスロックは完全に廃止されました (コマンドラインからオンにすることはできません)。

4. G1 の立ち上げ後、世代リサイクル戦略も変わりました。

JDK7 では G1 ガベージコレクターが導入されており、JDK9 ではデフォルトのガベージコレクターとして設定されているため、これについては誰もが比較的よく知っています。G1では、若い世代と古い世代という厳密な区分けはなく、同じ規模の複数の独立したエリアに分割されており、それぞれのエリアが異なる時点で異なる役割を果たします。

5. JDK と JRE の関係を考慮する必要はありません。

JDK と JRE はどちらも Java の重要な部分ですが、役割と用途は異なります。JDK は Java 開発キットであり、主に Java アプリケーションの開発に使用されます。これには JRE が含まれており、コンパイラ (javac)、デバッガ (jdb) などの追加ツールも提供されます。JRE は Java アプリケーションを実行するために必要な環境です。これには、Java 仮想マシン (JVM) と Java クラスライブラリが含まれています。これらは、Java アプリケーションの実行に必要なコアクラスとその他のサポートファイルです。

JDK 8 以前のバージョンでは、Oracle はユーザーがダウンロードできる独立した JRE と JDK を提供します。つまり、JRE をインストールして Java プログラムを実行することも、JDK をインストールして Java プログラムを開発することもできます。

ただし、JDK 9 以降、Oracle はJRE を個別にリリースしなくなりました。代わりに、カスタマイズされたランタイムイメージを生成するために使用できる jlink ツールがあります。このアプローチでは、アプリケーションとカスタムランタイムイメージを含むパッケージを配布するだけで済み、別個の JRE をインストールする必要がないため、Java アプリケーションのデプロイメントが簡素化されます。

6. ジェネリックはもはや「糖衣構文」ではないかもしれない

Java のジェネリックスについて話すとき、多くの人が最初に思い浮かべるのは「糖衣構文」と「型消去」です。型消去は、Java ジェネリックの実装メカニズムです。これは、コンパイル時にジェネリック型がその修飾型 (明示的に指定されていない場合は Object) に置き換えられ、バイトコードにはジェネリック情報が保持されないことを意味します。

たとえば、次のようなジェネリッククラスがあるとします。

public class Box<T> {
    private T object;

    public void set(T object) { this.object = object; }
    public T get() { return object; }
}

コンパイル後、このクラスは次のようになります。

public class Box {
    private Object object;

    public void set(Object object) { this.object = object; }
    public Object get() { return object; }
}

型消去の最大の利点は、ジェネリックスが導入される前の Java コードにはジェネリック情報がなかったため、古いバージョンの Java コードとの互換性が確保されることです。しかし、型の消去は結局のところ最後の手段であり、特定の型チェックを実行できない、メソッド署名の競合が発生するなど、いくつかの欠点があります。

次に、OpenJDK の長期プロジェクトである Project Valhalla が登場しました。その主な目標は、ジェネリックの特殊化を含む、Java にいくつかの改善と新機能を導入することです。Java でのジェネリックスの現在の実装では型消去が使用されています。これは、ジェネリック情報はコンパイル時にのみ存在し、実行時に消去されることを意味します。ジェネリックスの特殊化とは、ジェネリック情報を実行時まで保持できることを意味し、型パラメーターに基づいて特定のコードを生成できるようになり、実行時の効率が向上し、型の安全性が向上します。

しかし、ヴァルハラプロジェクトは少々規模が大きい上に進捗が比較的遅く、「冷めている」という意見も多い。それにもかかわらず、多くの新機能がプレビュー版に実装されており、将来的には正式版に登場する予定です。

7. Java はインターフェイスでプライベートメソッドを定義できる

Java のインターフェースの目的はパブリック API を定義することであり、メソッドの詳細を実装することではありません。そのため、デフォルトおよび静的メソッドは JDK8 より前にはサポートされていませんでした。ただし、便宜上、JDK8 はメソッドのデフォルト実装をサポートしているため、インターフェイスに多数の実装クラスがある場合でも、元の実装を破壊することなく API を反復できます。

JDK8 のインターフェイスクラスのデフォルト実装は、モデル抽象化における多くの問題を解決します。その後、インターフェイスのデフォルトメソッドが一部のコードセグメントを共有する必要がある場合、これらのコードセグメントは新しい関数に抽象化することしかできません。この関数が静的である場合 (JDK8 はインターフェイスで定義された静的関数をサポートします)、関数内で他の非静的 API にアクセスすることはできません。デフォルト実装の API である場合、実装クラスは自由にオーバーロードできます。そして最も重要なことは、API は何があっても公開されるということですが、これは開発者が望んでいることではありません。

最後に、JDK9 では、開発者がインターフェイスでプライベートメソッドを定義できるため、パブリックコードがデフォルトメソッドに抽出およびカプセル化され、コードの冗長性が削減されます。

著者 | 邱淮

元のリンク

この記事は Alibaba Cloud のオリジナルコンテンツであり、許可なく複製することはできません。