Javaの継続性

産業用ソフトウェアの際立った特徴は、非常に難しいことです...そのようなシステムの複雑さは人間の知的能力を超えています...この複雑さを克服することはできますが、決してそれをなくすことはできません。



グラディ・ブーチ

数十年前に戻って、それらの年の典型的なプログラムがどのように見えるか見てみましょう。 それから、命令的なアプローチが支配的でした。 計算プロセスをプログラムが完全に制御することで、その名前が付けられたことを思い出してください。プログラムは、何をいつ行うべきかを明確に示しています。 天皇の命令のセットのように。 ほとんどのオペレーティングシステムは、実行可能プログラムを作成するためにこのアプローチを提案しています。 たとえば、さまざまな種類のユーティリティを作成するときなど、今日まで広く使用されています。 さらに、このアプローチで、学校でのプログラミングの研究が始まります。 その人気の理由は何ですか？ 実際、命令型は非常にシンプルで理解しやすいものです。 マスターそれは難しくありません。



例を見てみましょう。 コードを古風なものにするためにPascalを選びました。 プログラムは、変数「x」の値を入力するようプロンプトを出し、入力された値をコンソールから読み取り、変数「y」についても同様に、最後に「x」と「y」の合計を表示します。 すべてのアクションは、プログラムによって開始されます（入力と出力の両方）。 厳密な順序で。

var x, y: integer; begin write('x = '); readln(x); write('y = '); readln(y); writeln('x + y = ', x + y); end.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、プログラムの主なアクションを強調するために、コードを少し書き直して、いくつかの抽象化を導入します（はい、「抽象化」という用語はOOPのプロパティではありません）。

 var x, y: integer; begin x := receiveArg; y := receiveArg; sendResult('x + y = ', x + y); end.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、抽象化を導入することは、抽象化なしで行うことが可能であると思われる場合に、複雑さを克服するもう1つのツールです。 クラスや可視性修飾子がない場合でも、これは同じカプセル化です。 後でこのコードを思い出します。 それまでの間、続けてください。



オペレーティングシステムの進化により、グラフィカルスキンが出現し、命令型スタイルが支配的になりました。 グラフィカルシェルを備えたOSは、プログラムの構造に対してまったく異なるアプローチ、いわゆる イベント駆動型アプローチ。 このアプローチの本質は、プログラムがほとんどの時間アイドル状態であり、何もせず、オペレーティングシステムからの「刺激物」にのみ応答することです。 事実、グラフィカルインターフェイスはユーザーにすべてのウィンドウコントロールへの同時アクセスを提供し、命令型プログラムの場合のようにそれらを順番に調べることはできません。 それどころか、ロジックによって提供される場合、またはユーザーによって期待される場合、プログラムはウィンドウの任意の部分でユーザーのアクションに即座に応答する必要があります。 イベント駆動型アプローチは、アプリケーション開発者の選択ではなく、OS開発者の選択です。 このモデルにより、マシンリソースをより効率的に使用できます。 さらに、OSはグラフィカルシェルを処理し、この意味で、クライアントプログラムとアプリケーションプログラムの間の「厚い」中間体です。 実際、技術的に適用されたプログラムは依然として不可欠です。 彼らは命令的な核小体、いわゆる メッセージループまたはイベントループ。 しかし、ほとんどの場合、この核小体は典型的であり、プログラマーが使用するグラフィックライブラリの腸に隠されています。



イベント駆動型アプローチは、ソフトウェア開発の進化的開発ですか？ むしろ、それは必要です。 単純で経済的であることが判明しました。 このアプローチには欠点が知られています。 まず第一に、命令型アプローチよりも不自然であり、追加のオーバーヘッドが発生しますが、それについては後で詳しく説明します。 この理由から、このアプローチについて話しました。実際、このアプローチはアプリケーションソフトウェアをはるかに超えて広がっています。 これが、ほとんどのサーバーの外部インターフェースの仕組みです。 大まかに言えば、典型的なサーバーは、実行できるコマンドのリストを宣言します。 グラフィックアプリケーションのように、サーバーは、処理可能な外部からイベントコマンドが到着するまでアイドル状態です。 イベント駆動アプローチがサーバーアーキテクチャに移行したのはなぜですか？ 結局のところ、OSのグラフィカルシェルの部分に制限はありません。 いくつかの理由があると思います：これは主に、使用されるネットワークプロトコルの機能（原則として、接続はクライアントによって開始される）と、マシンリソースを節約する同じ必要性であり、その消費はイベント駆動型アプローチで簡単に調整できます。

 Response onRequest(Request request) { switch (request.type) { case "sum": int x = request.get("x"); int y = request.get("y"); return new Response(x + y); ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、イベント駆動型アプローチの重大な欠点の1つに注目したいと思います。これは、多くのオーバーヘッドであり、サーバーの動作ロジックを反映するコードの明示的な抽象化の欠如です。 まず、サーバーが宣言するさまざまなコマンド間の関係を意味します。すべてのコマンドが独立しているわけではなく、特定の順序で実行する必要があるコマンドもあります。 しかし、以来 イベント駆動型を使用する場合、さまざまな操作間の関係を常に反映できるとは限りません。オーバーヘッドは、各操作のコンテキストを復元する形式で表示され、この操作を実行できることを確認するために必要な追加チェックの形式で表示されます。 言い換えると、サーバーによって実装されるプロトコルが複雑な場合、イベント駆動型アプローチを使用してリソースを節約することはそれほど明白ではありません。 しかし、それにもかかわらず、それを使用する他の正当な理由があります：使用される言語ツール、標準、およびライブラリは、開発者に選択肢を残しません。 ただし、ここ数年で発生した重要な変更について、およびこのアプローチが新しい現実とうまく適合することについてさらにお話ししたいと思います。



ここで、サーバーコードを記述するときに命令型スタイルも使用されることに注意する必要があります。これは、p2p接続、または使用されるリソースの量が制限されているゲームなどの「リアルタイム」プログラムに非常に適しており、サーバー側からの反応速度が非常に重要です。

 for (;;) { Request request = receive(); switch (request.type) { case "sum": int x = receiveInt(); int y = receiveInt(); send(new Response(x + y)); break; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

receiveArgおよびsendResultオペレーションを追加したPascalコードを思い出してください。 この例に見られるものと非常に似ていることに同意します。引数を順番に要求し、結果を送信します。 唯一の違いは、ここではコンソールの役割がクライアントとのネットワーク接続によって果たされることです。 命令型スタイルは、関連する操作を処理する際のオーバーヘッドを排除します。 ただし、後で説明する特別なメカニズムを使用しないと、マシンのリソースをより積極的に活用し、より多くの接続を提供するサーバーの実装には不適切です。 自分で判断する：イベント駆動型のアプローチで、スレッドが別の操作に割り当てられる場合、スレッドは少なくとも寿命がはるかに長いセッションに割り当てられます。 ネタバレ：命令型アプローチでリソースを積極的に使用することは、回復可能な欠点です。



次に、「典型的な」サーバー実装を見てみましょう。以下のコードはどのフレームワークにも接続されておらず、リクエスト処理スキームのみを反映しています。 基礎として、私はSMSコードによる確認で新しいユーザーを登録する手順を取りました。 この手順は、登録と確認の2つの関連操作で構成されます。

 Response onReceived(Request request) { switch (request.type) { case "register": User user = registerUser(request); user.confCode = generateConfirmationCode(); sendSms("Confirmation code " + user.confCode); return Response.ok; case "confirm": String code = request.get("code"); User user = lookupUser(request); if (user == null || !Objects.equals(code, user.confCode)) { return Response.fail; } return user.confirm() ? Response.ok : Response.fail; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードを見てみましょう。 登録操作。 ここでは、リクエストのデータを使用して新しいクライアントを作成します。 しかし、クライアントを作成するプロセスに含まれるものを考えてみましょう。これは、潜在的に、1つまたは複数の外部システムへの一連の呼び出し（コード生成、SMSの送信）、ディスク操作です。 たとえば、sendSms操作は、コードを含むSMSメッセージがユーザーに正常に送信された後にのみ制御を返します。 外部システムへの呼び出し（クエリの配信時間、処理時間、結果を戻す時間）およびディスク操作には時間がかかり、現在のストリームのダウンタイムにつながります。 注：生成されたコードをクライアントにバインドします（confCodeフィールド）。 実際、このリクエストを処理した後、ハンドラーを終了し、すべてのローカル変数がリセットされます。 確認要求が到着したときに、後続の比較のためにコードを保存する必要があります。 処理するとき、最初に実行コンテキストを復元します。 これらは、私が話したのと同じオーバーヘッドです。



この例のように、リクエストの同期処理は、貴重なシステムリソースのダウンタイムにつながる大量のブロッキング操作に関連付けられています。 そして、すべては問題ありませんが、サービスシステムは、スループットと応答時間に対するこれまで以上の要求に直面しています。 システムリソースのダウンタイムは容認できない贅沢になりつつあります。 チャートを見てみましょう。









ここでは、ブロッキングコールを示しました。 網掛け部分は単純な呼び出しフローです。 重要ですか？ システムで使用されるタイムアウトのサイズと数を思い出してください。 ダウンタイムの可能性について雄弁に説明します。 これは約ミリ秒ではなく、数十秒、時には数分です。 1000 TpSの負荷では、1秒のダウンタイムは、追加のリソースが割り当てられた処理のための1000の操作を意味します。



スループットを高め、応答時間を短縮するために、業界はどのソリューションを提供していますか？ たとえば、鉄の開発者はマルチコアを提供しています。 はい、これは単一のマシンの機能を拡張します。 イベント駆動型のアプローチは、そのスケーラビリティのおかげで、新しいリソースを簡単に利用します。 ただし、要求ハンドラーの同期実装により、スレッドの使用は非効率的になります。 そして、ここで非同期呼び出しが助けになります。









非同期呼び出しのタスクは、できるだけ早く操作を開始して制御を返すことです。 操作の結果、コールバック関数を取得し、追加のパラメーターとして渡します。 したがって、このような呼び出しの直後に、作業を続行するか、結果が得られるまで完了することができます。 サンプルを変更して、非同期スタイルで書き直しましょう。

 void onReceived(Request request) { switch (request.type) { case "register": registerUser(request, user -> { generateConfirmationCode(code -> { user.confCode = code; sendSms("Confirmation code " + code, () -> { reply(Response.ok); }); }); }); break; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、レジスタ操作を1つだけ指定しました。 しかし、非同期スタイルの主な欠点であるコードの最悪の可読性、サイズの増加を見るには、これですでに十分です。 一連の同期呼び出しではなく、コールバックの「ラダー」の出現。 この例は、ラムダのおかげでのみ許容できるように見えます。 それらがなければ、非同期コードの認識ははるかに困難になります。 つまり、Java言語は新しい要件にうまく適合していません。 非同期コードでの作業をより快適にするために必要なツールが不足しています。



どうする？ 同期コードでの作業の快適さを維持し、同時に非同期メカニズムを使用してその主要な欠点を取り除く方法はありますか？



はい、そのような方法があります。

継続

継続性は、（ループ、条件分岐、メソッド呼び出しなどに加えて）プログラム実行のコースを制御するための別のメカニズムであり、現在のスレッドのリリースで特定のポイントでメソッドの実行を一時停止できます。



このツールの主な成果物は次のとおりです。

• 一時停止可能なメソッド -無期限に一時停止してから再開できるメソッド
• コルーチン / ファイバーは一時停止時にスタックを保持します。 一時停止されたメソッドの実行を再開するために、スタックをネットワーク経由で別のマシンに転送できます
• CoIteratorを使用すると、ジェネレーター（Manaライブラリに実装）と呼ばれる種類のイテレーターを作成できます。

これは完全なリストではありません。 Channel 、 Reactive dataflow、 Actorなどのアーティファクトも非常に好奇心が強いですが、これらは個々の記事のトピックです。 ここでは考えません。



現在、継続は多くのWebフレームワークによってサポートされています。 残念ながら、Javaで継続を使用できる一般的なソリューションは、指で数えることができます。 最近まで、それらはすべて大部分が職人技（実験）または非常に時代遅れでした。

• Jau VM -JVMのアドオン、「実験的」プロジェクト（2005）
• JavaFlow-キャピタルライブラリの作成の試み、2008年以降サポートされていません
• jyield-小さな「実験的」プロジェクト（2010年2月）
• コルーチン -別の「パイロット」プロジェクト（2010年10月）
• jcontは比較的最近の試みです（2013）
• Matis Mans Continuationsライブラリ -私の意見では、Java用の最もシンプルで成功したソリューション

人間によって実装された概念は、シンプルで学びやすいです。 残念ながら、現在サポートされていません。 さらに、ライブラリを説明する元の記事は最近アクセスできなくなりました。



しかし、すべてがそれほど悪いわけではありません。 Parallel Universeの紳士たちは、Manaライブラリーを基礎として、それを作り直し、すでに重量のあるバージョンであるQuasarにしました 。



Quasarは、Manaライブラリから主要なアイデアを継承し、それらを開発して、インフラストラクチャを追加しました。 さらに、現時点では、これがJava 8で機能する唯一のソリューションです。



このツールは何を提供しますか？ まず、同期コードの可視性を失うことなく、非同期コードを記述する機会を得ます。 さらに、サーバー側のコードを命令型スタイルで記述できるようになりました。

 for (;;) { Request request = receive(); switch (request.type) { case "register": User user = registerUser(request); int confCode = generateConfirmationCode(); sendSms("Confirmation code " + confCode); reply(Response.confirm); String code = receiveConfirmationCode(); if (Objects.equals(code, confCode) && user.confirm()) { reply(Response.ok); } else { reply(Response.fail); } break; ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、同じユーザー登録の例です。 登録/ペアの確認リクエストの残りは1つのみであることに注意してください：登録。 消えてから確認 ここではもう彼は必要ありません。 この実装では、オーバーヘッドが最小限に抑えられます。操作のコンテキスト全体がローカル変数に保存されるため、ユーザーを再作成するために生成されたコードを覚える必要はありません。 登録して、コードを生成し、SMSを送信した後、クライアントからこのコードを受信するだけで、それ以上は受信しません。 多数の追加属性を含む新しいリクエストではなく、1つのコードのみです！



どのように機能しますか？ Manaライブラリーから始めることをお勧めします。 ライブラリには少数のクラスのみが含まれており、その主なものはコルーチンです。

 Coroutine co = new Coroutine(new CoroutineProto() { @Override public void coExecute() throws SuspendExecution { ... Coroutine.yield(); // suspend execution ... } }); ... co.run(); // run execution ... co.run(); // resume execution
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コルーチンは、本質的にRunnableのシェルです。 より正確には、標準のRunnndable用ではなく、このインターフェイスの特別なバージョンであるCoroutineProto用です。 コルーチンのタスクは、埋め込みタスクの実行が中断された瞬間のスタックの状態を保存することです。 コルーチン自体は何も実行しません。runメソッドによって開始された場合、ネストされたものの実行は、coExecuteメソッド内のコードの実行を停止または再開した後、再開します。 runメソッドからのコントロールは、coExecuteメソッドが作業を終了するか、静的なCoroutine.yieldメソッドを呼び出して一時停止した後に戻ります。 coExecuteメソッドの状態は、Couroutine.getStateを呼び出すことで確認できます。 実は、run、yield、getStateの3つのメソッドは、Coroutineクラスの意味のあるインターフェース全体を記述しています。 すべてが非常に簡単です。 SuspendExecution例外に注意してください。 まず、メソッドが一時停止する可能性があることを示すマーカーです。 Manaライブラリの特徴は、この例外が一時停止の瞬間に実際にスローされることです（唯一の「空の」インスタンス-スタックなし）。 この実行を「絞め殺す」ことはできません。 これは、ライブラリの欠点の1つです。



Corutin Manは、特別な種類の反復子を作成する1つのアプリケーション、ジェネレーターを見ました。 どうやら、Mana（および彼の前任者）は、発電機のサポートが以下を含む多くの言語で利用可能であるという事実に抑圧されていました C＃（利回りリターン、利回りブレーク）。 彼のライブラリーには、Iteratorインターフェースを実装する特別なCoIteratorクラスが含まれていました。 ジェネレーターを作成するには、CoIteratorを継承し、一時停止された抽象runメソッドを実装する必要があります。 CoIteratorコンストラクターで、抽象runメソッドにフィードするコルーチンが生成されます。

 class TestIterator extends CoIterator<String> { @Override public void run() throws SuspendExecution { produce("A"); produce("B"); for(int i = 0; i < 4; i++) { produce("C" + i); } produce("D"); produce("E"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ライブラリ内のManaのアイデアが明確になると、Quasarをマスターするのは簡単です。 Quasarはわずかに異なる用語を使用します。 たとえば、Quasarでコルーチンとして使用されるFiberは、実際にはストリームの軽量バージョンです（この用語はおそらく、かなり以前からファイバーが存在していたWin APIから借用されたものです）。 これを使用するのは、コルーチンと同じくらい簡単です。

 Fiber fiber = new Fiber (new SuspendableRunnable() { public void run() throws SuspendExecution, InterruptedException { ... Fiber.park(); // suspend execution ... } }).start(); // start execution ... fiber.unpark(); // resume execution
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、おなじみのSuspendExecutionを確認します。 ただし、クエーサーでは、彼は正直にマーカーの役割を果たしており、必須ではありません。 代わりに、@ Suspendableアノテーションを使用できます。

 class C implements I { @Suspendable public int f() { try { return g() * 2; } catch(SuspendExecution s) { assert false; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ほとんどすべてのインターフェイスの一時停止可能な実装を作成する機会がありますが、Manaライブラリではこれを行うことができず、マーカー例外が必要になりました。



Quasarライブラリには、非同期インターフェイスを擬似同期インターフェイスに「変える」ために必要なすべてのものがあり、クライアントコードに同期の可視性と非同期の効率性を提供します。 さらに、Fiberインスタンスはシリアル化可能です。 異なるマシンで部分的に実行できます。1つのノードで開始し、一時停止し、ネットワークを介して別のノードに転送し、そこで実行を再開します。



ファイバーのパワーを理解するために、次の状況を想像してみましょう。 リクエストの同期処理を行う古典的なサーバーがあるとします。 ユーザーのリクエストを処理し、サーバーが外部リソースに時々アクセスするようにします。 たとえば、データベースへ。 サーバーが機能するために1000個のスレッドを割り当てたとします。 そして今、ある時点で、外部リソースが「鈍化」し始めました。 この場合、このリソースにアクセスする際の新しいリクエストのハンドラーはフリーズし始め、フローをブロックします。 サーバーの負荷が高いと、スレッドプールはすぐに消費され、リダイレクトが開始されます。 スレッドプールが共通である場合、外部リソースに接続されていない要求もリダイレクトされます。 ただし、サーバーは何もしない場合があります。 システム全体のボトルネックは、負荷に対処できずに失敗した外部リソースでした。



繊維はどのように役立ちますか？ ファイバーは、同期ハンドラーを非同期に変えます。 これで、外部リソースにアクセスするときに、ストリームを安全にプールに戻し、現在の実行スタックを保存するためにマシンから少しのメモリのみを要求できます。 外部リソースから応答を受信すると、プール内の空きストリームを取得し、スタックを復元してリクエストの処理を続行します。 美人！



ただし、ここで予約を行う必要があります。これは、外部リソースへのインターフェイスが非同期の場合にのみ機能します。残念ながら、多くのライブラリは同期インターフェースのみを提供します。JDBCの典型的な例。ただし、Javaが非同期に向かっていることに注意してください。古いインターフェースは書き換えられ（NIO、AIO、CompletableFuture、Servlet 3.0）、新しいインターフェースは最初は非同期であることが多い（Netty、ZooKeeper）。



もちろん、私はOracleからこの方向への進展を見たいと思っています。作業は進行中ですが、非常に遅いため、Javaの次のバージョンでは継続のフルタイムサポートは予定されていません。Quasarライブラリが他に類を見ないものになることを期待しましょう。非同期コードの記述を簡単かつ便利にする、より多くの興味深いソリューションが見つかるでしょう。