Qual è la differenza tra proxy dinamico JDK e CGLib?

Nel caso del Proxy Design Pattern , qual è la differenza tra il Dynamic Proxy di JDK e le API di generazione di codice dinamico di terze parti come CGLib ?

Qual è la differenza tra l'utilizzo di entrambi gli approcci e quando si dovrebbe preferire uno rispetto all'altro?

Il proxy dinamico JDK può eseguire il proxy solo tramite l'interfaccia (quindi la classe target deve implementare un'interfaccia, che viene quindi implementata anche dalla classe proxy).

CGLIB (e javassist) possono creare un proxy tramite la sottoclasse. In questo scenario il proxy diventa una sottoclasse della classe target. Non sono necessarie interfacce.

Quindi i proxy dinamici Java possono eseguire il proxy: public class Foo implements iFoo dove CGLIB può eseguire il proxy:public class Foo

MODIFICARE:

Devo dire che, poiché javassist e CGLIB usano il proxy tramite la sottoclasse, questo è il motivo per cui non è possibile dichiarare i metodi finali o rendere la classe definitiva quando si utilizzano framework che si basano su questo. Ciò impedirebbe a queste librerie di consentire la sottoclasse della classe e la sostituzione dei metodi.

Differenze di funzionalità

• I proxy JDK consentono di implementare qualsiasi set di interfacce durante la sottoclasse Object. Qualsiasi metodo di interfaccia, più Object::hashCode, Object::equalse Object::toStringviene quindi inoltrato a un InvocationHandler. Inoltre, java.lang.reflect.Proxyè implementata l' interfaccia della libreria standard .

• cglib consente di implementare qualsiasi set di interfacce durante la sottoclasse di qualsiasi classe non finale. Inoltre, i metodi possono essere sovrascritti facoltativamente, ovvero non tutti i metodi non astratti devono essere intercettati. Inoltre, esistono diversi modi per implementare un metodo. Offre anche una InvocationHandlerclasse (in un pacchetto diverso), ma consente anche di chiamare super metodi usando intercettori più avanzati come ad esempio a MethodInterceptor. Inoltre, cglib può migliorare le prestazioni mediante intercettazioni specializzate come FixedValue. Una volta ho scritto un riassunto di diversi intercettori per cglib .

Differenze di prestazione

I proxy JDK sono implementati in modo piuttosto ingenuo con un solo dispatcher di intercettazione, il InvocationHandler. Ciò richiede l'invio di un metodo virtuale a un'implementazione che non può sempre essere integrata. Cglib consente di creare un codice byte specializzato che a volte può migliorare le prestazioni. Ecco alcuni confronti per l'implementazione di un'interfaccia con 18 metodi stub:

            cglib                   JDK proxy
creation    804.000     (1.899)     973.650     (1.624)
invocation    0.002     (0.000)       0.005     (0.000)

Il tempo è indicato in nanosecondi con deviazione standard tra parentesi graffe. Puoi trovare maggiori dettagli sul benchmark nel tutorial di Byte Buddy, in cui Byte Buddy è un'alternativa più moderna a cglib. Inoltre, nota che cglib non è più in fase di sviluppo attivo.

Proxy dinamico: implementazioni dinamiche di interfacce in fase di esecuzione utilizzando l' API di riflessione JDK .

Esempio: Spring utilizza proxy dinamici per le transazioni come segue:

Il proxy generato viene aggiunto al bean. Aggiunge un comportamento transnazionale al bean. Qui il proxy viene generato dinamicamente in fase di esecuzione utilizzando l'API Reflection JDK.

Quando un'applicazione viene arrestata, il proxy verrà distrutto e avremo solo interfaccia e bean sul file system.

Nell'esempio sopra abbiamo l'interfaccia. Ma nella maggior parte dell'implementazione dell'interfaccia non è la cosa migliore. Quindi il bean non implementa un'interfaccia, in quel caso usiamo l'ereditarietà:

Per generare tali proxy, Spring utilizza una libreria di terze parti chiamata CGLib .

CGLib ( C ode G eneration Lib rary) è basato su ASM , questo viene principalmente utilizzato per generare il bean che estende il proxy e aggiunge il comportamento del bean nei metodi proxy.

Esempi per proxy dinamico JDK e CGLib

Rif. Primavera

Dalla documentazione di primavera :

Spring AOP utilizza proxy dinamici JDK o CGLIB per creare il proxy per un determinato oggetto di destinazione. (I proxy dinamici JDK sono preferiti ogni volta che hai una scelta).

Se l'oggetto target da sottoporre a proxy implementa almeno un'interfaccia, verrà utilizzato un proxy dinamico JDK. Tutte le interfacce implementate dal tipo di destinazione verranno inviate in proxy. Se l'oggetto target non implementa alcuna interfaccia, verrà creato un proxy CGLIB.

Se si desidera forzare l'uso del proxy CGLIB (ad esempio, per eseguire il proxy di tutti i metodi definiti per l'oggetto di destinazione, non solo quelli implementati dalle sue interfacce), è possibile farlo. Tuttavia, ci sono alcuni problemi da considerare:

i metodi finali non possono essere consigliati, in quanto non possono essere sostituiti.

Avrai bisogno dei binari CGLIB 2 sul tuo percorso di classe, mentre i proxy dinamici sono disponibili con JDK. Spring ti avviserà automaticamente quando è necessario CGLIB e le classi della libreria CGLIB non si trovano sul percorso di classe.

Il costruttore del tuo oggetto proxy verrà chiamato due volte. Questa è una conseguenza naturale del modello proxy CGLIB in base al quale viene generata una sottoclasse per ciascun oggetto proxy. Per ogni istanza proxy, vengono creati due oggetti: l'oggetto proxy effettivo e un'istanza della sottoclasse che implementa il consiglio. Questo comportamento non viene mostrato quando si utilizzano proxy JDK. Di solito, chiamare il costruttore del tipo proxy due volte non è un problema, poiché di solito ci sono solo assegnazioni in corso e nessuna logica reale è implementata nel costruttore.