JCoro​​-Javaのコルーチンの非同期性

この分野の研究は、「 非同期：バックトゥザフューチャー」という記事に触発されました。 その中で、著者は、 コルーチンを使用して、通常の同期コードと同じように見えるように非同期コードを単純化することが可能であるが、非同期操作の使用によって得られるバンズを保持する方法のアイデアを説明します。 要するに、アプローチの本質はこれです：実行コンテキストを保存および復元できるメカニズムがある場合（コルーチンのサポート）、コールバックチェーンのコード

startReadSocket((data) -> { startWriteFile(data, (result) -> { if (result == ok) ... }); }); 

次のように書き換えることができます。

 data = readSocket(); result = writeFile(data); if (result == ok) ... 

ここで、readSocket（）およびwriteFile（）は、非同期操作が次のように呼び出されるコルーチンです。

 byte[] readSocket() { byte[] result = null; startReadSocket((data) -> { result = data; resume(); }); yield(); return result; } 

yield（）およびresume（）メソッドは、すべてのフレームとローカル変数とともに実行コンテキストを保存および復元します。 次のことが起こります。readSocket（）を呼び出すとき、startReadSocket（）を呼び出してyield（）を実行することで非同期操作を計画します。 Yield（）は実行コンテキストを保存し、スレッドは終了します（プールに戻ります）。 非同期操作が完了すると、コールバックを終了する前にresume（）を呼び出して、コードの実行を再開します。 コントロールは再びwriteFile（）を呼び出すメイン関数を受け取ります。 writeFile（）は構造が似ており、すべてが繰り返されます。

使用されたすべての非同期操作に対して一度このような変換を行い、取得した関数をライブラリに配置すると、通常の同期コードであるかのように非同期コードを作成できるツールが得られます。 同期コード（可読性、便利なエラー処理）と非同期（パフォーマンス）の利点を組み合わせる機会が得られます。 この利便性に対する支払いは、何らかの形で実行コンテキストを保存および復元する必要があることです。 この記事では、著者はC ++での実装について説明していますが、Javaでそのようなものを取得したかったのです。 これについて説明します。

javaflow

まず、JVMのコルーチンの実装を見つける必要がありました。 いくつかのオプションの中で、javaflowライブラリが最も適していることが判明しました。 実験には非常に適していますが、残念ながら、プロジェクトは長い間放棄されています。 生成されたコードにワンド（逆コンパイラー）を挿入すると、javaflowにいくつかの重大な問題があることがわかりました。

• ラムダはまったくサポートされていません。 ライブラリの最後のリリースが2008年であったことを考えると、これは驚くことではありません。
• コードのインスツルメントは非常に不十分です。メソッド内のすべての呼び出しはインスツルメントされますが、それらのほとんどはサスペンド（）コールにつながることはありません。 その結果、バイトコードが大きく膨らみ、実際にはこのようなアプローチは受け入れがたいほど動作が遅くなります。
• 反射のサポートはありません。 コードの実行中にリフレクションを介してメソッドを呼び出すことができる場合、javaflowはこの場所で実行コンテキストを保存および復元できません。 そして、これは日常のプログラミングでは非常に重要であり、原則的な可能性の問題でさえありませんが、ほとんどすべての人がリフレクションを介して機能するDIコンテナを使用しているという事実です。 したがって、リフレクションを禁止することはできません;これはプログラマーにとって非常に強い制限です。

これにもかかわらず、javaflowは状態を保存および復元する方法を見つけるのに役立ちました。 その後、2つのオプションがありました。javaflowをサポートするか、実装を作成してください。 明らかな理由（致命的な欠陥）のため、2番目の方法が選択されました。

ジェイコロ

存在しない言語に追加されたコルーチンは、それを拡張します。 提案されたアプローチを完全に活用し、同時に誓うことのないアプリケーションを作成するには、それらを便利にする必要があります。 コードを読むと、この関数がコルーチンであり、非同期操作を実行することがすぐにわかるはずです。したがって、スタックの保存と復元のサポートのコンテキスト内で起動する必要があります。 C＃には、このためのasyncおよびawaitキーワードがあります。 Javaでは、残念ながら、キーワードを追加することは現実的ではありませんが、アノテーションを使用できます。 もちろん、これはすべてかさばりますが、どうすればいいのでしょう。 他の何かが出てくるかもしれません それまでの間、このように：

 Coro coro = Coro.initSuspended(new ICoroRunnable() { @Override @Async({@Await("foo")}) public void run() { int i = 5; double f = 10; final String argStr = foo(i, f, "argStr"); } @Async(@Await("yield")) private String foo(int x, double y, String m) { Coro c = Coro.get(); c.yield(); return "returnedStr"; } }); coro.start(); coro.resume(); 

@Asyncアノテーションの存在は、jcoroにこのメソッドのバイトコードをインストルメントし、コルーチンにするように指示します。 復旧ポイントの署名は、@ Awaitアノテーションによって定義されます。 @ Awaitアノテーションのリストに署名が含まれるコルーチン内のすべての呼び出しが回復ポイントになります。 jcoroのコルーチンは、@ Asyncアノテーションでマークされ、少なくとも1つの復元ポイントを持つメソッドです。 メソッドに単一の復元ポイントがない場合、インストルメントされません。 復元ポイントは、Coro.yield（）への呼び出し、または最終的にCoro.yield（）への呼び出しにつながる可能性のある呼び出し（コルーチン）です。

これは非同期アプリケーションの作成にどのように役立ちますか？

リクエストに応じてデータベースにアクセスし、データを処理してからテンプレートに適用し、マークアップを返すサーバーアプリケーションを作成する必要があるとします。 クラシックWebサーバーアプリケーション。 ほとんどすべての段階で、非同期操作を使用できます。 接続の確立、要求の受信時のソケットからのデータの読み取り、データベースとのすべてのネットワーク操作、テンプレートのロード時のファイルの読み取り、結果のソケットへの送信。 このシナリオのCPUは、非同期操作、データ前処理ロジック、およびテンプレートの計画でのみ忙しいはずです。 残りの時間、プロセッサは休むことができます。 これをコードでどのように整理できるかを考えてみましょう。 サーバーをスケッチしましょう：

 public static void main(String[] args) { Coro.initSuspended(new ICoroRunnable() { @Async({@Await("accept")}) public void run() { final AsynchronousServerSocketChannel listener = bind(new InetSocketAddress(5000)); //     ,       ExecutorService executorService = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors()); while (true) { AsynchronousSocketChannel channel = accept(listener); //   executorService.submit(new Runnable() { @Override public void run() { Coro.initSuspended(new ICoroRunnable() { @Async({@Await("handle")}) public void run() { //    -       , //        handle(channel); } }).start(); } }); } } }).start(); } @Async({@Await("read"), @Await("write")}) public static void handle(AsynchronousSocketChannel channel) { ByteBuffer buffer = ByteBuffer.allocate(10 * 1024); Integer read = read(channel, buffer); //   write(channel, outBuffer); //   channel.close(); } 

正しいコンパイルに必要な一部のtry-catchブロックはコードで省略されています。これは、コードを読みやすくするために行われます。

ハンドル内には、任意のロジックを追加できます。 たとえば、「コントローラー」を定義し、リフレクション、依存性注入を通じてそれを呼び出します。 ただし、リフレクションライブラリまたはインストルメント化されていないライブラリを介したリカバリポイントを含むコードの呼び出しには注意する必要があります。 詳細については、以下をご覧ください。

ストリーム使用率の観点から、これは次のように機能します。 ワーカースレッドのプールがあり、非同期操作のコールバックを実行するためにJVMが予約するシステムスレッドプールがあります。 非同期操作が完了すると、スレッドの1つがコールバックを開始します。 まず、コルーチンの状態が復元され、次にコルーチンの実行が継続され、完了または次の非同期操作に到達します。 コルーチンが終了した後（または次の非同期操作をスケジュールした後に実行を一時停止した後）、スレッドはプールに戻ります。 したがって、1つのリクエストを別のスレッドで順番に処理することができ、これによりコードにいくつかの制限が課せられます。 したがって、たとえば、putとgetの間でコルーチンの実行が中断されないという確実性がない場合、スレッドローカル変数を使用できません。 一方、回路は最適に近いように見え、良好なパフォーマンスを約束します。

実装

javaflowとは異なり、jcoroはすべてのメソッドとその中のすべての呼び出しを計測しません。 インスツルメンテーションの対象となるのはコルーチンのみです-少なくとも1つの復元ポイントがあるメソッド。 復元ポイントは、実行されると最終的にyield（）の呼び出しにつながる呼び出しです。 つまり、これはすべての課題で発生する必要はなく、理論的な可能性で十分です。 通常、コードはどのように計測されますか？ スレッド全体の実行状態を保存および復元するにはどうすればよいですか？ これはまったく難しいことではないことがわかりました。 コルーチンの誇りあるタイトルであると主張する各方法を小さな状態機械に変えるのに十分です。 これを行うには、メソッドの先頭にバイトコードを追加します。これは、回復する必要がない場合は何も行いません。必要に応じて切り替え（状態）を実行し、状態の値によって、実行が中断された回復ポイントの呼び出しに切り替えます。 状態の保存はリカバリポイントの呼び出し時にのみ発生するため、これで十分です（yield（）の呼び出し自体もリカバリポイントです）。 それに加えて、ローカル変数とフレームスタックを復元することを忘れないでください。 JVMのフレームの状態はこのセット（スタックの状態、ローカル変数、現在の命令）によって一意に識別されるため、この後はすべてが正常に機能していると主張できます。 同様に、実行スタック全体でsave-restoreを実行します。

例に戻って、それがどうなるか見てみましょう。

 @Async(@Await("yield")) private String foo(int a, double b, String c) { Coro c = Coro.get(); c.yield(); return "returnedStr"; } 

このコルーチンは何の役にも立たず、作業を一時停止するだけで、その後値を返します。 バイトコードでは、次のようになります。

 private java.lang.String foo(int, double, java.lang.String); descriptor: (IDLjava/lang/String;)Ljava/lang/String; flags: ACC_PRIVATE Code: stack=1, locals=6, args_size=4 0000: invokestatic org/jcoro/Coro.get:()Lorg/jcoro/Coro; 0003: astore 5 0005: aload 5 0007: invokevirtual org/jcoro/Coro.yield:()V 0010: ldc "returnedStr" 0012: areturn 

インストルメンテーション後、これが表示されます（結果は統一された差分の形式になりますが、残念ながらHabrは文字列の強調表示をサポートしていません）。

 private java.lang.String foo(int, double, java.lang.String); descriptor: (IDLjava/lang/String;)Ljava/lang/String; flags: ACC_PRIVATE Code: - stack=1, locals=6, args_size=4 + stack=2, locals=6, args_size=4 + 0: invokestatic org/jcoro/Coro.getSafe:()Lorg/jcoro/Coro; //    + 3: ifnull 0000 //    -     + 6: invokestatic org/jcoro/Coro.popState:()Ljava/lang/Integer; // popState()    null,     + 9: dup + 10: ifnull 32 //     -     + 13: invokestatic org/jcoro/Coro.isUnpatchableCall:()Z //      + 16: ifeq 23 + 19: invokestatic org/jcoro/Coro.popRef:()Ljava/lang/Object; + 22: pop + 23: ldc 0 + 25: invokestatic org/jcoro/Coro.setUnpatchableCall:(Z)V + 28: pop + 29: goto 43 + 32: pop 0000: invokestatic org/jcoro/Coro.get:()Lorg/jcoro/Coro; //       0003: astore 5 0005: aload 5 + 40: goto 0007 //  -        + 43: invokestatic org/jcoro/Coro.popRef:()Ljava/lang/Object; + 46: checkcast "Lorg/jcoro/Coro;" + 49: astore 5 + 51: invokestatic org/jcoro/Coro.popRef:()Ljava/lang/Object; + 54: checkcast "Ljava/lang/String;" + 57: astore 4 + 59: invokestatic org/jcoro/Coro.popDouble:()D + 62: dstore_2 + 63: invokestatic org/jcoro/Coro.popInt:()I + 66: istore_1 + 67: invokestatic org/jcoro/Coro.popRef:()Ljava/lang/Object; + 70: checkcast "Lorg/jcoro/tests/SimpleTest$1;" + 73: astore_0 + 74: invokestatic org/jcoro/Coro.popRef:()Ljava/lang/Object; + 77: checkcast "Lorg/jcoro/Coro;" 0007: invokevirtual org/jcoro/Coro.yield:()V //   + 83: invokestatic org/jcoro/Coro.isYielding:()Z //  -    + 86: ifeq 0010 + 89: aload_0 + 90: invokestatic org/jcoro/Coro.pushRef:(Ljava/lang/Object;)V + 93: iload_1 + 94: invokestatic org/jcoro/Coro.pushInt:(I)V + 97: dload_2 + 98: invokestatic org/jcoro/Coro.pushDouble:(D)V + 101: aload 4 + 103: invokestatic org/jcoro/Coro.pushRef:(Ljava/lang/Object;)V + 106: aload 5 + 108: invokestatic org/jcoro/Coro.pushRef:(Ljava/lang/Object;)V + 111: aload_0 + 112: invokestatic org/jcoro/Coro.pushRef:(Ljava/lang/Object;)V + 115: ldc 0 + 117: invokestatic org/jcoro/Coro.pushState:(I)V + 120: aconst_null //  null,     + 121: areturn 0010: ldc "returnedStr" //    0012: areturn 

メソッドの最初に、復旧ポイントを識別するコードが追加されました。復旧ポイントの前後には、復元および保存するコードが追加されました。 より多くの復旧ポイントがある場合、最初に、単純な移行の代わりに、切り替えが表示されます。 もう1つ微妙な違いがあります。 並列スタックを使用してフレームを保存および復元するため、オブジェクトを追加および受信する順序に従う必要があります。 最初にオブジェクトAをスタックに配置し、次にBを配置した場合、それらを逆の順序で受け取る必要があります。 したがって、最初にローカル変数を保存し、次にフレームスタックを保存する場合、逆に復元を実行する必要があります。 そして、ここでのプラスは、呼び出しオブジェクトへの参照の処理です（これ）。 保存すると、極端なスタックとしてスタックにプッシュされ、リカバリ中に最初に取得されます（もちろん、リカバリポイントが非静的な方法でない限り）。 上記の例にはローカル変数はありませんが、それらを使用するとコードはほぼ同じになります。

パッチできないコード

残念ながら、スタックを保存および復元するための上記の戦略は、すべてのコルーチンを計測できる場合にのみ機能します。 リカバリポイントを含むメソッドをインスツルメントできない場合、この戦略は機能しません。 これは、反射またはインストルメントできないライブラリを介してコードを呼び出す場合に可能です。 そして、まだライブラリを使用して何かを考えることができる場合、反射なしで、まあ、方法はありません。 すべてのプログラマーは、DIコンテナー、プロキシー、およびAOPを使用したいと考えています。 ただし、ほとんどの場合、これらのタイプの呼び出しは完全にステートレスです。つまり、呼び出しを行わない呼び出しの数は、基本的に制御をさらに転送するだけです。 そして、コルーチンを再開するときに、このメソッドをもう一度呼び出すことができます。同じメソッドに引数を渡すだけです。 そして、彼が呼び出すコードでは、状態を復元し続けています。 また、このメカニズムをサポートするには、2番目の状態保存戦略のみが必要です。この戦略では、呼び出しの後ではなく呼び出しの前に引数が保存されます。 この戦略は現在jcoroでサポートされており、使用するには、リカバリポイントを@Await（patchable = false）としてマークする必要があります。

メソッドの呼び出しが各戦略を使用することに関する情報は、 wikiで見つけることができます 。

Lambdサポート

ラムダはサポートされていますが、曲がっています。 2つの問題があります。 その1つは、Javaではラムダに注釈を付けるのが難しく、さらに読みにくいことです。 私が見つけた唯一の解決策は、最近登場したタイプ注釈に基づいており、次のようになります：

 Coro coro = Coro.initSuspended((@Async({@Await(value = "yield")}) ICoroRunnable) () -> { Coro.get().yield(); }); 

コンパイラはこれを認識すると、クラスファイルに注釈を追加し、それをinvokedynamic命令に関連付けます。 そして、それは動作しますが、残念ながら、常にではありません。 コンパイラは、このような注釈をこの命令ではなく以前の命令に関連付ける場合があり（おそらくこれはバグです）、場合によってはクラスファイルに注釈をまったく書き込まないことがあります。 たとえば、これはそのようなコードをコンパイルするときに起こります：

  public static void main(String[] args) { Runnable one = (@TypeAnn("1") Runnable) () -> { Runnable two = (@TypeAnn("2") Runnable) () -> { Runnable three = (@TypeAnn("3") Runnable) () -> { Runnable four = (@TypeAnn("4") Runnable) () -> { }; }; }; }; } 

クラスファイルでは、外側の2つのラムダのinvokedynamic命令のみに注釈が付けられます。 また、コンパイラーは、内側の2つのラムダの注釈を無視します。 これもバグである可能性が高いため、Oracleに送信しましたが、確認はまだ受けていません。 これがうまくいくことを願っています。

2番目の問題は、ラムダがJavaの世界ではかなり奇妙な生き物であることです。 これらはインスタンスメソッドと呼ばれますが、実際には静的メソッドです。 そして、この波動粒子の二重性は、保存修復メカニズムの概念的な問題を生み出します。 事実、最適なリカバリ戦略を実現するには、これをインスタンスメソッドの本体に保存する必要があります（ 図を参照）。 ただし、呼び出し元のコードのみが機能インターフェイスのインスタンスへのリンクを持っています！ 最後に、ラムダを実行する前に引数の保存、つまりpatchable = false（リフレクションの問題を回避することを目的とした）と同じオプションを使用する必要があります。 そして、それはもっとゆっくり働きます。 ただし、各ラムダコルーチンでpatchable = falseを登録する必要があるために生じる不便と比較して、おそらくこれは重要ではありません。

これら2つの問題をまとめると、残念な結論を導き出すことができます。ラムダコルーチンをまだ使用することはお勧めできません。

現在の状況と計画

このプロジェクトはhttps://github.com/elw00d/jcoroで入手できます 。 エンジン、そのテストのセット 、およびいくつかの例が利用可能になりました。 テクノロジーを思い起こさせるには、次のことを行う必要があります。

1. — stack map frames
2. maven gradle jar- class-
3. , 3 . , — ( nio, jcoro), — jcoro. , - , . , .
4. . . . , , jdbc. - «» jdbc, — mysql, postgresql, mssql. — jcoro, . — - -.
5. IntelliJ IDEA, . - , ( @Await , @Async) .
6. , User Guide .

あなたがビジネスでjcoroを助けたり試してみたいという願望を持っているなら、ようこそ！パブリックコミュニケーションでは、おそらくGithub Issuesを使用する最も簡単な方法です。