web-dev-qa-db-ja.com

Java)で利用可能なコルーチンライブラリ

Javaでいくつかのことをしたいのですが、並行ルーチンを使用して記述した場合はより明確になりますが、フルオンスレッドは深刻なやり過ぎです。もちろん、答えは-の使用です。 coroutines ですが、標準のJavaライブラリにはコルーチンがサポートされていないようです。Googleで簡単に説明すると、あちこちで魅力的なヒントが表示されますが、実質的なものはありません。 。

これが私がこれまでに見つけたものです:

  • [〜#〜] jsim [〜#〜] はコルーチンクラスを持っていますが、かなり重く見え、ポイントにスレッドがあるように見えます。これのポイントは、フルオンスレッドの複雑さを軽減することであり、追加することではありません。さらに、クラスをライブラリから抽出して独立して使用できるかどうかもわかりません。
  • Xalan には、コルーチンのようなことを行うコルーチンセットクラスがありますが、これがライブラリ全体から有意義に抽出できるかどうかは疑わしいです。また、実際のコルーチンとしてではなく、厳密に制御された形式のスレッドプールとして実装されているようにも見えます。
  • Google Codeプロジェクト があります。これは私が求めているもののように見えますが、どちらかといえばスレッドを使用するよりも重いように見えます。私は基本的に、ソフトウェアが実行時にJVMバイトコードを動的に変更して作業を行う必要があることに神経質になっています。これはやり過ぎのようであり、コルーチンが解決するよりも多くの問題を引き起こすもののように見えます。さらに、コルーチンの概念全体を実装していないようです。一見すると、呼び出し元に戻るだけのyield機能が提供されます。適切なコルーチンにより、yieldsは制御を既知のコルーチンに直接転送できます。基本的に、このライブラリは、重量があり怖いので、完全に一般的なコルーチンではなく、イテレータのみをサポートします。
  • 有望な名前の Coroutine for Java は、プラットフォーム固有の(明らかにJNIを使​​用する)ソリューションであるため失敗します。

そして、それは私が見つけたすべてについてです。

Da Vinci MachineでのコルーチンのネイティブJVMサポートについて知っています。また、これを行うための JNI継続トリック についても知っています。ただし、これらは私にとって本当に良い解決策ではありません。コードを実行するVMまたはプラットフォーム)を必ずしも制御できるとは限らないからです(実際、バイトコード操作システムでも同様の問題が発生します-この純粋なJava。ランタイムバイトコード操作により、たとえばAndroidでこれを使用できなくなります。)

それで、誰かが何かポインタを持っていますか?これも可能ですか?そうでない場合、Java 7で可能ですか?


編集して追加:

混乱が含まれていることを確認するために、これは関連する質問です 他の質問 ですが、同じではありません。これは、不必要に車輪の再発明を避けるために、既存の実装を探しています。もう1つは、Javaでコルーチンを実装する方法に関する質問です。この質問に答えられないことが判明した場合。目的は、さまざまなスレッドでさまざまな質問を保持することです。


さらに編集して追加:

回答が選択されています 。ただし、いくつかの解説は適切です。指摘されたライブラリはコルーチンライブラリではないので、技術的には私の質問に答えません。とはいえ、上記にリンクされているGoogleCodeプロジェクトには2つの利点があります。

  1. どちらのソリューションもバイトコード操作を使用しますが、選択したライブラリはstaticバイトコード操作を許可し、Androidおよびその他の非準拠のJVMスタックで使用できるようにします。
  2. GoogleCodeプロジェクトは完全なコルーチンを実行しません。回答のライブラリはコルーチンをまったく実行しませんが、より重要なことを実行します。それは、私自身のフル機能のコルーチンをローリングするための優れた基本的なツールを提供します。

Javaflow は継続的な実装であり、おそらくそれを可能にします。ただし、バイトコード操作を使用します。

とにかく、プレーンCでOOPを実行しようとしているように感じます。実行可能ですが、実行する必要があるという意味ではありません。

12
Guillaume

Kilim フレームワークは、バイトコードの書き換えを使用してコルーチンを実装します。 Erjang で軽量プロセスを実装するために自分で使用しましたが、非常に安定しており、バイトコードの書き換え量に対して驚くほど高速です。

Kilimのコルーチンはメールボックスを使用して相互作用するため、フレームワークを使用してErlangアクターをモデル化します。ただし、共有メモリモデルでコルーチンを実行するためにも使用できます。

11

Matthias Mannによって書かれたこの継続ライブラリについてどう思いますか?議論を容易にするために、作成者のWebサイトから賛否両論をコピーしました。ソースコードのテストを見て、Webサイトの1つの例を超えて確認することが重要です。

http://www.matthiasmann.de/content/view/24/26/

あなたが得るものから始めましょう:

  • 単純なシーケンシャルコードを書く-ステートマシンを手動で作成する必要がなくなりました
  • スレッドは作成または必要ありません-マルチスレッド同期の問題はありません
  • コード実行によるゴミの作成はありません
  • 実行時のオーバーヘッドが非常に小さい
  • 一時停止可能なメソッド呼び出しのみが変更されます。標準ライブラリ(Java.util。*など)へのすべての呼び出しはまったく影響を受けません。
  • 完全なシリアル化のサポート
  • コルーチンの実行状態は、追加のコードなしで、ゲーム状態の一部としてセーブゲームに保存できます。もちろん、これには、コルーチンで使用するクラスとデータ型がシリアル化可能である必要があります。例外処理と最終ブロックの完全サポート
  • オフライン前処理によってアプリケーションのロード時間が遅くなることはありません。もちろん、ランタイムインストルメンテーションも可能です。
  • 非常に小さなランタイムライブラリ-10Kバイト未満(非圧縮JAR)BSDライセンス

これらすべての優れた機能により、欠点を求めているかもしれません。もちろん、いくつかの欠点があります。

  • コンストラクターと静的初期化子は一時停止できません
  • サスペンド可能なメソッドを同期できないか、ブロックを同期できません
  • インストルメンテーションタスクを実行するには、ASM3ライブラリをダウンロードする必要があります
  • リフレクションでサスペンド可能なメソッドを呼び出すことはできません

同期の問題は、同期の使用を必要とするコードを独自のメソッドに配置することで回避できます。

9
rrmckinley

要件は次のようです。

  • 軽量-スレッドに基づかない、
  • ネイティブコードに依存せず、
  • バイトコードの変更は使用しません。

これらの要件により、Javaでコルーチンを実装するためのすべての賢明な戦略が除外されていると私は不快に感じています。

5
Stephen C

Javaを使用している場合、2017年後半の時点で利用可能な2つのオプションがあります。

これらは両方ともcommons-javaflowに基づいています-それらは物事を機能させるためにバイトコードレベルでコードを書き直します。

私は維持します コルーチン -利点は、高速であり、すべての主要なビルドシステムをサポートし、コルーチンのシリアル化/バージョン管理をサポートすることです。欠点は、APIにcommons-javaflowからのいくつかの逸脱があることです。

Vsilaevは維持します Tascalate-Javaflow -私はそれを使用していないのでそれについて話すことはできませんが、それは維持されており、例を見ると、APIはcommons-javaflowのAPIに近くなっています。

KotlinとScala(およびおそらく他のJVMベースの言語)には、コルーチンを使用できる言語機能もあります。ただし、言語を切り替える前に、Kotlin、Scala、またはその他の言語に注意する必要があります。現在のJVM言語dujourは、Javaではなく、今後もJavaになることはありません。バックグラウンドで機能させるために行っていることは、JVMの次のリリースがロールアラウンドするときに機能しない可能性があります。

OracleでJDKを管理している人々は、これらのサードパーティのJVM言語を市場調査として使用した実績があります。高レベルの機能がサードパーティのJVM言語に追加され、それが十分に普及している場合、彼らはそれをJavaに組み込みます。これは、コルーチンで現在起こっていることです。 Java言語にコルーチンを追加することを目的とした Project Loom というOpenJDKプロジェクトがあります。

ProjectLoomはまだ初期の段階です。あなたが提案を批判的に見るならば、それは混乱です。時間が経つにつれて安定すると確信していますが、最終的に得られるものは、多くの人が期待しているものとはまったく異なる可能性があります。

要約すると、オプションは、バイトコードインストルメンテーションツールキットの1つを使用するか、言語を切り替えることです。 Project Loomはまだ初期段階であり、実際にはJavaに追加されない可能性があります。

4
offbynull

play Frameworkは、Javaflowの継続を提供するようになりました。 Playは他の分野でも非常に便利なので、最初から始めることをお勧めします。

http://www.playframework.org/documentation/1.2RC2/releasenotes-1.2#Continuations

2
rrmckinley

Javaで利用できる新しいコルーチンフレームワークライブラリがあります。純粋なJavaで実装されているため、JNIやJavaエージェントを個別に実行する必要はありません。オープンソースであり、GitHubからダウンロードできます。

https://github.com/esoco/coroutines

フレームワークの概要は、Mediumにあります。

https://medium.com/@esocogmbh/65661a379c85

1
eso

Quasar 実装 Go-like coroutines 継続を使用する他の機能の中でもチャネル。

私の 別の答え のQuasarに関する詳細、ベンチマーク、およびリンク。

0
Vadzim