リスナーに強制的に反映させないでください

はじめに

開発プロセスでは、多くの場合、XML構成ファイルに名前が格納されているクラスのインスタンスを作成するか、名前がアノテーション属性の値として文字列として書き込まれているメソッドを呼び出す必要があります。 そのような場合、答えは「リフレクションを使用してください！」です。

CUBAプラットフォームの新しいバージョンでは、フレームワークを改善するためのタスクの1つは、UI画面のコントローラークラスでのイベントハンドラーの明示的な作成を取り除くことでした。 以前のバージョンでは、コントローラーの初期化メソッドでのハンドラー宣言はコードで非常に乱雑だったため、7番目のバージョンではすべてを完全に削除することを断固として決定しました。

イベントリスナーは、適切なタイミングで呼び出す必要があるメソッドへの単なる参照です（ Observerテンプレートを参照）。 このようなテンプレートは、 java.lang.reflect.Method



クラスを使用して実装するのが非常に簡単です。 開始時には、フレームワークの大部分で行われているように、クラスをスキャンし、それらから注釈付きメソッドを抽出し、それらへの参照を保存し、イベントが発生したときにリンクを使用してメソッドを呼び出します。 私たちを止めた唯一のことは、多くのイベントが伝統的にUIで生成されることであり、リフレクションAPIを使用する場合、メソッド呼び出しの時間の形でいくらかの価格を支払う必要があります。 したがって、リフレクションを使用せずにイベントハンドラーを作成する方法を検討することにしました。

既にMethodHandlesとLambdaMetafactoryに関する資料をhabrで公開しており 、この資料は一種の継続です。 リフレクションAPIの長所と短所、および代替案（AOTコンパイルとLambdaMetafactoryを使用したコードの生成、CUBAフレームワークでの使用方法）を調べます。

リフレクション：古い。 いいね 信頼できる

コンピューターサイエンスでは、リフレクションまたはリフレクション（イントロスペクションの略語、英語のリフレクション）は、実行時にプログラムが独自の構造と動作を追跡および変更できるプロセスを意味します。 （c）ウィキペディア。

ほとんどのJava開発者にとって、リフレクションは決して新しいものではありません。 このメカニズムがなければ、Javaはアプリケーションソフトウェア開発で大きな市場シェアを占めるJavaにはならなかったように思えます。 考えてみてください：プロキシ、アノテーションを介したメソッドのイベントへのバインド、依存関係の注入、アスペクト、そしてJDKの最初のバージョンでのJDBCドライバーのインスタンス化さえ！ どこでもリフレクションは、現代のすべてのフレームワークの基礎です。

タスクに適用されるReflectionに問題はありますか？ 次の3つを特定しました。

速度 -Reflection APIを介したメソッドの呼び出しは、直接呼び出しよりも遅くなります。 JVMの各新バージョンでは、開発者はリフレクションを介して呼び出しを絶えずスピードアップし、JITコンパイラーはコードをさらに最適化しようとしますが、とにかく、直接メソッド呼び出しとの違いは顕著です。

入力 -コードでjava.lang.reflect.Method



を使用する場合、これはメソッドへの単なる参照です。 また、渡されるパラメータの数とタイプはどこにも書かれていません。 誤ったパラメーターを使用した呼び出しは、アプリケーションのコンパイルまたはダウンロードの段階ではなく、実行時にエラーを生成します。

透明性 -リフレクションを介して呼び出されたメソッドが失敗した場合、エラーの実際の原因の底に到達する前に、いくつかのinvoke()



コールを処理する必要があります。

しかし、HibernateでSpringまたはJPAイベントハンドラーのコードを調べると、内部には古くからあるjava.lang.reflect.Method



あります。 そして、近い将来、これが変わることはまずないと思います。 これらのフレームワークは大きすぎ、それらに結び付けられすぎており、サーバー側のイベントハンドラーのパフォーマンスは、どの呼び出しをリフレクションに置き換えることができるかを考えるのに十分であるようです。

そして、他にどんなオプションがありますか？

AOTのコンパイルとコード生成-アプリケーションに速度を戻します！

リフレクションAPIを置き換える最初の候補はコード生成です。 現在、 MicronautやQuarkusなどのフレームワークが登場し始めており、アプリケーションの起動速度の低下とメモリ消費の削減という2つの問題を解決しようとしています。 これら2つのメトリックは、コンテナ、マイクロサービス、サーバーレスアーキテクチャの時代に不可欠であり、新しいフレームワークはAOTコンパイルによってこれを解決しようとしています。 さまざまな手法を使用して（たとえば、 ここで読むことができます）、アプリケーションコードは、メソッド、コンストラクターなどへのすべての再帰呼び出しが行われるように変更されます。 直接呼び出しに置き換えられました。 したがって、アプリケーションの起動時にクラスをスキャンしてBeanを作成する必要はなく、JITは実行時にコードをより効率的に最適化します。これにより、このようなフレームワーク上に構築されたアプリケーションのパフォーマンスが大幅に向上します。 このアプローチには欠点がありますか？ 回答：もちろんあります。

最初に、作成したコードを実行しません。ソースコードはコンパイル中に変更されるため、何か問題が発生した場合、コードまたは生成アルゴリズム（通常はもちろん）でエラーの場所を理解することが困難な場合があります） そして、ここからデバッグの問題が発生します-独自のコードをデバッグする必要があります。

2番目-AOTコンパイルを使用してフレームワークで記述されたアプリケーションを実行するには、特別なツールが必要です。 たとえば、Quarkusで書かれたアプリケーションをそのまま実行することはできません。 コードを前処理するmaven / gradle用の特別なプラグインが必要です。 そして今、フレームワークでエラーが発生した場合、ライブラリだけでなくプラグインも更新する必要があります。

実際、Javaの世界ではコード生成も新しいものではなく、 MicronautやQuarkusでは発生しませんでした 。 何らかの形で、いくつかのフレームワークはそれを使用します。 ここでは、アスペクトまたはeclipselinkの予備的なコード生成であるlombok、aspectjを思い出すことができます。これにより、エンティティクラスにコードが追加され、より効率的な逆シリアル化が行われます。 CUBAでは、コード生成を使用して、エンティティの状態の変化に関するイベントを生成し、クラスコードに検証メッセージを含めて、UIでのエンティティの操作を簡素化します。

CUBA開発者にとって、イベントハンドラーの静的コード生成の実装は、内部アーキテクチャとコード生成のプラグインで多くの変更を行う必要があるため、少し極端なステップになります。 反射のように見えるが高速なものはありますか

LambdaMetafactory-同じメソッド呼び出しですが、より高速です

Java 7では、JVMに新しい命令invokedynamic



導入されました。 彼女については、 ここでjug.ruに関するウラジミール・イワノフによる素晴らしい報告があります 。 もともとGroovyのような動的言語で使用するために考案されたこの命令は、リフレクションを使用せずにJavaでメソッドを呼び出すための素晴らしい候補でした。 新しい命令とともに、関連するAPIがJDKに登場しました。

• MethodHandle
  
  
  
  クラスMethodHandle
  
  
  
  7で登場しましたが、まだあまり使用されていません
• LambdaMetafactory
  
  
  
  このクラスはすでにJava 8からのもので、動的呼び出し用のAPIのさらなる開発となり、 MethodHandle
  
  
  
  内部で使用しています。

本質的にメソッド（コンストラクターなど）への型付きポインターであるMethodHandle



、 java.lang.reflect.Method



の役割を果たすことができるように思われました。 また、各呼び出しでReflection APIで実行されるすべてのタイプチェックは、この場合、 MethodHandle



ときに1回だけ実行されるため、呼び出しは高速になります。

しかし、 MethodHandle



、純粋なMethodHandle



はリフレクションAPIを介した呼び出しよりもさらに遅いことが判明しました。 MethodHandle



静的にすることでパフォーマンスを向上させることができますが、すべての場合ではありません。 OpenJDKメーリングリストでMethodHandle



呼び出しの速度について優れた議論があります 。

しかし、 LambdaMetafactory



クラスLambdaMetafactory



とき、メソッド呼び出しを高速化する本当のチャンスがありました。 LambdaMetafactory



使用LambdaMetafactory



と、ラムダオブジェクトを作成し、その中に直接メソッド呼び出しをラップすることができます。これは、 MethodHandle



から取得できます。 そして、生成されたオブジェクトを使用して、目的のメソッドを呼び出すことができます。 BiFunctionにパラメーターとして渡されるゲッターメソッドをラップする生成の例を次に示します。

 private BiFunction createGetHandlerLambda(Object bean, Method method) throws Throwable { MethodHandles.Lookup caller = MethodHandles.lookup(); CallSite site = LambdaMetafactory.metafactory(caller, "apply", MethodType.methodType(BiFunction.class), MethodType.methodType(Object.class, Object.class, Object.class), caller.findVirtual(bean.getClass(), method.getName(), MethodType.methodType(method.getReturnType(), method.getParameterTypes()[0])), MethodType.methodType(method.getReturnType(), bean.getClass(), method.getParameterTypes()[0])); MethodHandle factory = site.getTarget(); BiFunction listenerMethod = (BiFunction) factory.invoke(); return listenerMethod; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、MethodではなくBiFunctionのインスタンスを取得します。 そして、コードでMethodを使用した場合でも、それをBiFunctionに置き換えることは難しくありません。 Spring Frameworkから@EventListener



とマークされたメソッドハンドラーを呼び出すための実際の（少し簡略化された、真の）コードを見てみましょう。

 public class ApplicationListenerMethodAdapter implements GenericApplicationListener { private final Method method; public void onApplicationEvent(ApplicationEvent event) { Object bean = getTargetBean(); Object result = this.method.invoke(bean, event); handleResult(result); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、これは同じコードですが、ラムダを介したメソッド呼び出しを使用しています：

 public class ApplicationListenerLambdaAdapter extends ApplicationListenerMethodAdapter { private final BiFunction funHandler; public void onApplicationEvent(ApplicationEvent event) { Object bean = getTargetBean(); Object result = funHandler.apply(bean, event); handleResult(result); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最小限の変更、機能は同じですが、利点があります：

ラムダには型があります-作成時に指定されるため、「メソッドだけ」の呼び出しは失敗します。

トレーススタックは短くなります -ラムダを介してメソッドを呼び出す場合、追加の呼び出しが1つだけ追加されapply()



。 そしてそれだけです。 次に、メソッド自体が呼び出されます。

ただし、速度を測定する必要があります。

速度を測定する

仮説をテストするために、 JMHを使用してマイクロベンチマークを作成し、リフレクションAPI、LambdaMetafactoryを介して同じメソッドを呼び出すときの実行時間とスループットを比較し、比較のための直接メソッド呼び出しも追加しました。 メソッドとラムダへのリンクは、テストの開始前に作成およびキャッシュされました。

テストパラメータ：

 @BenchmarkMode({Mode.Throughput, Mode.AverageTime}) @Warmup(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS) @Measurement(iterations = 10, time = 1000, timeUnit = TimeUnit.MILLISECONDS)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テスト自体は、 GitHubからダウンロードして 、必要に応じて自分で実行できます。

Oracle JDK 11.0.2およびJMH 1.21のテスト結果（数値は異なる場合がありますが、違いは顕著でほぼ同じです）：

テスト-値を取得	スループット（ops / us）	実行時間（us / op）
LambdaGetTest	72	0.0118
ReflectionGetTest	65	0.0177
DirectMethodGetTest	260	0.0048
テスト-設定値	スループット（ops / us）	実行時間（us / op
LambdaSetTest	96	0.0092
ReflectionSetTest	58	0.0173
DirectMethodSetTest	415	0.0031

平均して、ラムダを介したメソッドの呼び出しは、リフレクションAPIを使用した場合よりも約30％高速であることが判明しました。 誰かが詳細に興味がある場合は、 ここでメソッド呼び出しのパフォーマンスについて別の素晴らしい議論があります。 簡単に言えば、生成されたラムダをプログラムコードにインライン化でき、リフレクションとは異なり、タイプチェックがまだ実行されていないという事実により、速度の向上が得られます。

もちろん、このベンチマークは非常に単純であり、クラス階層内のメソッドの呼び出しや、最終メソッドの呼び出し速度の測定は含まれていません。 しかし、より複雑な測定を行い、結果は常にLambdaMetafactoryの使用を支持していました。

使用する

CUBAバージョン7フレームワークのUIコントローラーでは、 @Subscribe



アノテーションを使用して、特定のユーザーインターフェイスイベントにメソッドに「署名」できます。 内部的には、これはLambdaMetafactory



に実装されてLambdaMetafactory



、リスナーメソッドへのリンクは最初の呼び出しで作成およびキャッシュされます。

この革新により、特に多数の要素、複雑な相互作用、したがって多数のイベントハンドラーを含むフォームの場合に、コードを大幅にクリアすることが可能になりました。 CUBAクイックスタートの簡単な例：アイテムを追加または削除するときに注文額を再計算する必要があると想像してください。 エンティティでコレクションが変更されたときにcalculateAmount()



メソッドを実行するコードを記述する必要があります。 以前の様子：

 public class OrderEdit extends AbstractEditor<Order> { @Inject private CollectionDatasource<OrderLine, UUID> linesDs; @Override public void init( Map<String, Object> params) { linesDs.addCollectionChangeListener(e -> calculateAmount()); } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、CUBA 7では、コードは次のようになります。

 public class OrderEdit extends StandardEditor<Order> { @Subscribe(id = "linesDc", target = Target.DATA_CONTAINER) protected void onOrderLinesDcCollectionChange (CollectionChangeEvent<OrderLine> event) { calculateAmount(); } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論：コードは簡潔であり、マジックinit()



メソッドはありません。このメソッドは、フォームの複雑さが増すにつれて、イベントハンドラーを拡張して埋めることができます。 しかも-購読しているコンポーネントでフィールドを作成する必要さえありません。CUBAはこのコンポーネントをIDで検索します。

結論

AOTコンパイルを備えた新世代のフレームワーク（ Micronaut 、 Quarkus ）の出現にも関わらず、「伝統的な」フレームワーク（主にSpringと比較されます）に比べて否定できない利点がありますが、リフレクションAPIを使用して記述された大量のコードがまだあります（そして、同じ春に感謝します）。 そして、Spring Frameworkは現在もアプリケーション開発フレームワークのリーダーであり、今後もリフレクションベースのコードを使用していく予定です。

また、コードでReflection APIを使用することを考えている場合（アプリケーションであろうとフレームワークであろうと）、よく考えてください。 まず、コード生成について、次にMethodHandles / LambdaMetafactoryについて。 2番目の方法はより高速であることが判明し、Reflection APIを使用する場合よりも開発作業が費やされることはありません。

さらに便利なリンク：

Java Reflectionのより高速な代替手段

Javaでのラムダ式のハッキング

Javaのメソッドハンドル

Java Reflection、ただしはるかに高速

LambdaMetafactoryが静的MethodHandleより10％遅いが、非静的MethodHandleより80％速いのはなぜですか？

速すぎる、大きすぎる：Javaでのメソッド呼び出しのパフォーマンスに影響を与えるものは何ですか？