श्रोताओं को प्रतिबिंबित करने के लिए मजबूर न करें

परिचय

विकास प्रक्रिया के दौरान, अक्सर एक वर्ग का एक उदाहरण बनाना आवश्यक होता है जिसका नाम एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में संग्रहीत होता है, या एक विधि को कॉल करने के लिए जिसका नाम स्ट्रिंग के रूप में एनोटेशन विशेषता के मूल्य के रूप में लिखा जाता है। ऐसे मामलों में, उत्तर एक है: "प्रतिबिंब का उपयोग करें!"।

सीयूबीए प्लेटफॉर्म के नए संस्करण में , फ्रेम को बेहतर बनाने के कार्यों में से एक यूआई स्क्रीन के नियंत्रक वर्गों में घटना संचालकों के स्पष्ट निर्माण से छुटकारा पाना था। पिछले संस्करणों में, कंट्रोलर इनिशियलाइज़ेशन मेथड में हैंडलर की घोषणाओं को कोड के साथ जोड़ा गया था, इसलिए सातवें संस्करण में हमने सब कुछ साफ करने का निर्णय लिया।

एक इवेंट श्रोता केवल उस विधि का संदर्भ है जिसे सही समय पर ( ऑब्जर्वर टेम्पलेट देखें) कहा जाता है। इस तरह का टेम्पलेट java.lang.reflect.Method वर्ग का उपयोग करके लागू करने के लिए काफी सरल है। स्टार्टअप पर, आपको बस कक्षाओं को स्कैन करने की जरूरत है, उनमें से एनोटेट विधियों को बाहर निकालें, उनके संदर्भों को सहेजें, और लिंक का उपयोग विधि (या विधियों) को करने के लिए करते हैं जब घटना होती है, जैसा कि फ्रेमवर्क के थोक में किया जाता है। केवल एक चीज जो हमें रोकती थी, वह यह था कि बहुत सारी घटनाएं यूआई में पारंपरिक रूप से उत्पन्न होती हैं, और प्रतिबिंब एपीआई का उपयोग करते समय, आपको विधि कॉल के समय के रूप में कुछ कीमत चुकानी होगी। इसलिए, हमने यह देखने का निर्णय लिया कि आप प्रतिबिंब का उपयोग किए बिना इवेंट हैंडलर कैसे बना सकते हैं।

हमने पहले ही मेथडैंडल्स और लैम्बडामेटैफ़ैक्ट्री के बारे में सामग्री एक हाब पर प्रकाशित की है , और यह सामग्री एक प्रकार की निरंतरता है। हम प्रतिबिंब एपीआई का उपयोग करने के पेशेवरों और विपक्षों के साथ-साथ विकल्प - एओटी संकलन और लैंबडामेटिफैक्ट के साथ कोड बनाने की जांच करेंगे, और यह सीयूबीए ढांचे में कैसे उपयोग किया गया था।

परावर्तन: पुराना। अच्छा। विश्वसनीय

कंप्यूटर विज्ञान में, परावर्तन या परावर्तन (आत्मनिरीक्षण का नाम, अंग्रेजी प्रतिबिंब) का अर्थ है एक प्रक्रिया जिसके दौरान कोई प्रोग्राम रनटाइम पर अपनी संरचना और व्यवहार को ट्रैक और संशोधित कर सकता है। (c) विकिपीडिया।

अधिकांश जावा डेवलपर्स के लिए, प्रतिबिंब कभी भी नई चीज नहीं है। यह मुझे लगता है कि इस तंत्र के बिना, जावा वह जावा नहीं बन जाता, जो अब एप्लिकेशन सॉफ्टवेयर विकास में एक बड़े बाजार में हिस्सेदारी रखता है। जरा सोचिए: एनोडेशन, डिपेंडेंसी इंजेक्शन, पहलुओं और यहां तक ​​कि जेडीबीसी ड्राइवर को जेडीके के पहले संस्करणों में तत्काल जोड़ना, घटनाओं के माध्यम से समीपवर्ती, बाध्यकारी तरीकों! हर जगह परावर्तन, सभी आधुनिक रूपरेखाओं की आधारशिला है।

क्या हमारे कार्य पर लागू होने पर प्रतिबिंब के साथ कोई समस्या है? हमने तीन की पहचान की है:

स्पीड - रिफ्लेक्शन एपीआई के माध्यम से एक विधि कॉल प्रत्यक्ष कॉल की तुलना में धीमी है। जेवीएम के प्रत्येक नए संस्करण में, डेवलपर्स लगातार प्रतिबिंब के माध्यम से कॉल को गति देते हैं, जेआईटी कंपाइलर कोड को और भी अधिक अनुकूलित करने का प्रयास करता है, लेकिन वैसे भी, प्रत्यक्ष विधि कॉल की तुलना में अंतर ध्यान देने योग्य है।

टाइपिंग - यदि आप कोड में java.lang.reflect.Method का उपयोग करते java.lang.reflect.Method , तो यह केवल कुछ विधि का संदर्भ है। और कहीं नहीं लिखा है कि कितने पैरामीटर पास किए गए हैं और वे किस प्रकार के हैं। गलत मापदंडों के साथ एक कॉल रनटाइम में एक त्रुटि उत्पन्न करेगा, और एप्लिकेशन को संकलन या डाउनलोड करने के चरण में नहीं।

पारदर्शिता - यदि प्रतिबिंब के माध्यम से बुलाया जाने वाला तरीका विफल हो जाता है, तो हमें त्रुटि के वास्तविक कारण की तह तक पहुंचने से पहले कई invoke() कॉल से गुजरना होगा।

लेकिन अगर हम हाइबरनेट में स्प्रिंग या जेपीए इवेंट हैंडलर्स के कोड को देखें, तो अच्छा पुराना java.lang.reflect.Method अंदर होगा। और निकट भविष्य में, मुझे लगता है कि यह बदलने की संभावना नहीं है। ये चौखटे बहुत बड़े और उनसे बहुत अधिक बंधे होते हैं, और ऐसा लगता है कि सर्वर-साइड पर ईवेंट हैंडलर का प्रदर्शन यह सोचने के लिए पर्याप्त है कि आप प्रतिबिंब के माध्यम से कॉल को क्या बदल सकते हैं।

और क्या अन्य विकल्प हैं?

एओटी संकलन और कोड पीढ़ी - एप्लिकेशन को वापस गति दें!

प्रतिबिंब एपीआई को बदलने वाला पहला उम्मीदवार कोड पीढ़ी है। अब माइक्रोनॉट या क्वार्कस जैसे ढांचे दिखाई देने लगे हैं, जो दो समस्याओं को हल करने की कोशिश कर रहे हैं: एप्लिकेशन की लॉन्च गति को कम करना और मेमोरी की खपत को कम करना। हमारे कंटेनर, माइक्रोसर्विस और सर्वर रहित आर्किटेक्चर में ये दो मैट्रिक्स महत्वपूर्ण हैं, और नए ढांचे एओटी संकलन द्वारा इसे हल करने की कोशिश कर रहे हैं। विभिन्न तकनीकों का उपयोग करना (आप यहां पढ़ सकते हैं, उदाहरण के लिए), आवेदन कोड को इस तरह से संशोधित किया जाता है कि सभी रिफ्लेक्टिव तरीके, विधियां, आदि। प्रत्यक्ष कॉल द्वारा प्रतिस्थापित किया गया। इस प्रकार, आपको एप्लिकेशन स्टार्टअप समय पर कक्षाओं को स्कैन करने और बीन्स बनाने की आवश्यकता नहीं है, और जेआईटी रन समय में कोड को अधिक कुशलता से अनुकूलित करता है, जो इस तरह के फ्रेमवर्क पर बनाए गए अनुप्रयोगों के प्रदर्शन में महत्वपूर्ण वृद्धि देता है। क्या इस दृष्टिकोण के नुकसान हैं? उत्तर: बेशक है।

सबसे पहले, आप उस कोड को नहीं चलाते हैं जो आपने लिखा था। संकलन के दौरान स्रोत कोड बदल जाता है, इसलिए यदि कुछ गलत हो जाता है, तो कभी-कभी यह समझना मुश्किल होता है कि त्रुटि कहां है: आपके कोड में या पीढ़ी एल्गोरिथ्म में (आमतौर पर आपकी, निश्चित रूप से) )। और यहाँ से डिबगिंग की समस्या उत्पन्न होती है - आपको अपना कोड डीबग करना होगा।

दूसरा - एओटी संकलन के साथ ढांचे में लिखे गए एप्लिकेशन को चलाने के लिए, आपको एक विशेष उपकरण की आवश्यकता है। आप उदाहरण के लिए, क्वार्कस में लिखे गए एप्लिकेशन को केवल प्राप्त और चला नहीं सकते। हमें मावेन / ग्रेडेल के लिए एक विशेष प्लगइन की आवश्यकता है, जो आपके कोड को पूर्व-संसाधित करेगा। और अब, ढांचे में त्रुटियों के मामले में, आपको न केवल पुस्तकालयों, बल्कि प्लगइन को भी अपडेट करने की आवश्यकता है।

सच में, जावा दुनिया में कोड जनरेशन भी कोई नई बात नहीं है, यह माइक्रोनॉट या क्वार्कस के साथ दिखाई नहीं दिया। एक या दूसरे रूप में, कुछ ढांचे इसका उपयोग करते हैं। यहाँ हम लुम्बोक को याद कर सकते हैं, पहलुओं या एक्लिप्सिंक के लिए अपनी प्रारंभिक पीढ़ी के कोडेज़ के साथ, जो और अधिक कुशल deserialization के लिए इकाई वर्गों के लिए कोड जोड़ता है। CUBA में, हम एक इकाई की स्थिति में परिवर्तन के बारे में घटनाओं को उत्पन्न करने के लिए और यूआई में संस्थाओं के साथ काम करने को सरल बनाने के लिए वर्ग कोड में सत्यापनकर्ता संदेशों को शामिल करने के लिए कोड पीढ़ी का उपयोग करते हैं।

सीयूबीए डेवलपर्स के लिए, इवेंट हैंडलर्स के लिए स्टैटिक कोड जेनरेशन को लागू करना एक चरम कदम होगा क्योंकि कोड आर्किटेक्चर के लिए आंतरिक आर्किटेक्चर और प्लगइन में बहुत सारे बदलाव किए जाने थे। क्या ऐसा कुछ है जो प्रतिबिंब की तरह दिखता है लेकिन तेज है?

लेम्बडामेटिफैक्ट - समान विधि कॉल, लेकिन तेज

जावा 7 ने जेवीएम के लिए एक नया निर्देश पेश किया - invokedynamic । उसके बारे में व्लादिमीर इवानोव द्वारा jug.ru पर एक उत्कृष्ट रिपोर्ट है। मूल रूप से ग्रूवी जैसी गतिशील भाषाओं में उपयोग के लिए कल्पना की गई थी, यह निर्देश जावा में प्रतिबिंब का उपयोग किए बिना तरीकों को लागू करने के लिए एक महान उम्मीदवार था। नए निर्देश के साथ ही, JDK में एक संबद्ध API दिखाई दिया:

• कक्षा MethodHandle - जावा 7 में वापस दिखाई दिया, लेकिन अभी भी बहुत बार उपयोग नहीं किया जाता है
• LambdaMetafactory - यह वर्ग पहले से ही जावा 8 से है, यह डायनेमिक कॉल के लिए एपीआई का एक और विकास बन गया है, अंदर MethodHandle का उपयोग करता है।

ऐसा लगता था कि MethodHandle अनिवार्य रूप से एक विधि (निर्माता, आदि) के लिए एक टाइप्ड पॉइंटर होने के MethodHandle , java.lang.reflect.Method की भूमिका को पूरा करने में सक्षम होगा। और कॉल तेजी से होंगे, क्योंकि प्रत्येक प्रकार की जांच जो प्रत्येक कॉल के साथ परावर्तन एपीआई में की जाती है, इस मामले में, केवल एक बार किया जाता है, जब MethodHandle ।

लेकिन अफसोस, शुद्ध MethodHandle प्रतिबिंब एपीआई के माध्यम से कॉल की तुलना में भी धीमा हो गया। 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; } 

परिणामस्वरूप, हमें विधि के बजाय BiFunction का एक उदाहरण मिलता है। और अब, यहां तक ​​कि अगर हमने अपने कोड में मेथड का इस्तेमाल किया है, तो इसे BiFunction के साथ बदलना मुश्किल नहीं है। स्प्रिंग फ्रेमवर्क से @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); } } 

न्यूनतम परिवर्तन, कार्यक्षमता समान है, लेकिन इसके फायदे हैं:

एक लंबोदर का एक प्रकार है - यह निर्माण में निर्दिष्ट है, इसलिए "बस एक विधि" को कॉल करना विफल हो जाएगा।

ट्रेस स्टैक छोटा होता है - एक लैम्बडा के माध्यम से एक विधि को कॉल करते समय, केवल एक अतिरिक्त कॉल जोड़ा जाता है - apply() । और वह सब है। इसके बाद, विधि को ही कहा जाता है।

लेकिन गति को मापा जाना चाहिए।

गति को मापें

परिकल्पना का परीक्षण करने के लिए, हमने JMH का उपयोग करते हुए निष्पादन समय और थ्रूपुट की अलग-अलग तरीकों से कॉल करने के लिए एक माइक्रोबेनमार्क बनाया: प्रतिबिंब एपीआई के माध्यम से, लैम्बडामेटिफैक्ट के माध्यम से, और तुलना के लिए एक सीधा विधि कॉल भी जोड़ा। टेस्ट शुरू होने से पहले मेथड और लैम्ब्डा के लिंक बनाए गए और कैश किए गए।

परीक्षण पैरामीटर:

 @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 के लिए परीक्षा परिणाम (संख्या भिन्न हो सकती है, लेकिन अंतर ध्यान देने योग्य है और उसी के बारे में):

औसतन, यह पता चला कि एक लंबो के माध्यम से एक विधि को कॉल करना एक प्रतिबिंब एपीआई के माध्यम से लगभग 30% तेज है। अगर किसी को विवरण में रुचि है, तो विधि आह्वान प्रदर्शन के बारे में एक और महान चर्चा है। संक्षेप में - गति में लाभ इस तथ्य के कारण भी प्राप्त होता है कि उत्पन्न लैम्ब्डा को प्रोग्राम कोड में इनलाइन किया जा सकता है, और प्रतिबिंब के विपरीत, प्रकार की जांच अभी तक नहीं की जाती है।

बेशक, यह बेंचमार्क काफी सरल है, इसमें क्लास पदानुक्रम में कॉलिंग मेथड्स को शामिल करना या अंतिम तरीकों को कॉल करने की गति को मापना शामिल नहीं है। लेकिन हमने और अधिक जटिल माप किए, और परिणाम हमेशा लेम्बडामेटिफैक्ट के उपयोग के पक्ष में थे।

के उपयोग

@Subscribe संस्करण 7 फ्रेमवर्क में, यूआई नियंत्रकों में, आप कुछ उपयोगकर्ता इंटरफ़ेस घटनाओं के लिए एक विधि "साइन" करने के लिए @Subscribe एनोटेशन का उपयोग कर सकते हैं। आंतरिक रूप से, यह LambdaMetafactory पर लागू किया LambdaMetafactory , श्रोता तरीकों के लिंक पहले कॉल पर बनाए और कैश किए जाते हैं।

इस नवाचार ने कोड को स्पष्ट करना संभव बना दिया, विशेष रूप से बड़ी संख्या में तत्वों के साथ रूपों के मामले में, जटिल बातचीत और, तदनुसार, बड़ी संख्या में घटना संचालकों के साथ। सीयूबीए क्विकस्टार्ट का एक सरल उदाहरण: कल्पना करें कि आपको उत्पाद आइटमों को जोड़ने या हटाने के दौरान ऑर्डर राशि को पुनर्गणना करने की आवश्यकता है। आपको कोड लिखने की आवश्यकता है जो कि इकाई में संग्रह में परिवर्तन होने पर CalculAmount 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 को यह घटक आईडी द्वारा मिलेगा।

निष्कर्ष

एओटी संकलन ( माइक्रोनॉट , क्वार्कस ) के साथ फ्रेमवर्क की एक नई पीढ़ी के उद्भव के बावजूद, जो "पारंपरिक" फ्रेमवर्क (मुख्य रूप से, वे वसंत के साथ तुलना में) पर निर्विवाद फायदे हैं, प्रतिबिंब एपीआई का उपयोग करते हुए कोड की एक बड़ी मात्रा अभी भी है। (और सभी एक ही वसंत के लिए धन्यवाद)। और ऐसा लगता है कि स्प्रिंग फ्रेमवर्क वर्तमान में अभी भी एप्लिकेशन डेवलपमेंट फ्रेमवर्क के बीच अग्रणी है और हम आने वाले लंबे समय के लिए प्रतिबिंब आधारित कोड के साथ काम करेंगे।

और अगर आप अपने कोड में परावर्तन एपीआई का उपयोग करने के बारे में सोच रहे हैं - चाहे वह एक आवेदन हो या एक रूपरेखा - दो बार सोचें। पहले, कोड पीढ़ी के बारे में, और फिर मेथडैंडल / लैम्बडामेटिफैक्ट के बारे में। दूसरी विधि अधिक तेज़ हो सकती है, और विकास के प्रयास से अधिक खर्च नहीं किया जाएगा यदि प्रतिबिंब एपीआई का उपयोग किया गया था।

कुछ और उपयोगी लिंक:
जावा परावर्तन का एक तेज़ विकल्प
जावा में लैम्ब्डा एक्सप्रेशंस हैक करना
जावा में मेथड हैंडल
जावा परावर्तन, लेकिन बहुत तेज
लैंबडामैटैफैक्टिक स्टैटिक मेथडैंडल की तुलना में 10% धीमा क्यों है, लेकिन एक गैर-स्टैटिक मेथैंडल की तुलना में 80% तेज है?
टू फास्ट, टू मेगामॉर्फिक: जावा में विधि कॉल प्रदर्शन को क्या प्रभावित करता है?