पीवीएस-स्टूडियो स्टेटिक कोड एनालाइजर द्वारा अपाचे डब्बो आरपीसी फ्रेमवर्क का विश्लेषण

Apache Dubbo GitHub पर सबसे लोकप्रिय जावा प्रोजेक्ट्स में से एक है। यह आश्चर्य की बात नहीं है। यह 8 साल पहले बनाया गया था और इसे व्यापक रूप से उच्च प्रदर्शन वाले आरपीसी वातावरण के रूप में लागू किया गया था। बेशक, इसके कोड के अधिकांश बग लंबे समय से तय किए गए हैं और कोड की गुणवत्ता उच्च स्तर पर बनी हुई है। हालाँकि, पीवीएस-स्टूडियो स्टैटिक कोड एनालाइज़र का उपयोग करके ऐसी दिलचस्प परियोजना की जाँच करने का कोई विकल्प नहीं है। आइए देखें कि यह कैसे निकला।

पीवीएस-स्टूडियो के बारे में

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

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

इसके अलावा विकल्प हैं कि आप खुले स्रोत परियोजनाओं में मुफ्त के लिए पीवीएस-स्टूडियो का उपयोग कैसे कर सकते हैं या यदि आप एक छात्र हैं।

Apache Dubbo: यह क्या है और मुख्य विशेषताएं

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

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

विश्लेषण के बारे में

विश्लेषण का कार्य क्रम काफी सरल है और मेरे मामले में अधिक समय की आवश्यकता नहीं है:

• GitHub से Apache Dubbo डाउनलोड किया गया;
• स्टार्ट-अप जावा विश्लेषक के निर्देशों का इस्तेमाल किया और विश्लेषण चलाया;
• विश्लेषक की रिपोर्ट मिली, इसकी समीक्षा की और दिलचस्प मामलों को उजागर किया।

विश्लेषण के परिणाम: निश्चितता के उच्च और मध्यम स्तर (क्रमशः 46 और 27) की 73 चेतावनियाँ 4000+ फाइलों के लिए जारी की गईं, जो कोड गुणवत्ता का एक अच्छा संकेतक है।

सभी चेतावनियाँ त्रुटियाँ नहीं हैं। यह एक सामान्य परिणाम है, जैसा कि सीधे विश्लेषक का उपयोग करने से पहले, किसी को इसे कॉन्फ़िगर करना होगा। उसके बाद, आप झूठी सकारात्मक ( उदाहरण ) के काफी कम प्रतिशत की उम्मीद कर सकते हैं।

मैंने 9 चेतावनियों (7 उच्च और 2 मध्यम) पर विचार नहीं किया, परीक्षण के साथ फाइलों से संबंधित।

नतीजतन, मेरे पास कम संख्या में चेतावनी थी, जिसमें गलत सकारात्मकता भी शामिल थी, क्योंकि मैंने विश्लेषक को कॉन्फ़िगर नहीं किया है। लेख में आगे के विवरण के साथ सभी 73 चेतावनियों में देरी लंबी, हास्यास्पद और थकाऊ है, इसलिए मैंने सबसे अधिक खुश रहने वाले लोगों को चुना।

जावा में बाइट साइन करें

V6007 अभिव्यक्ति 'endKey [i] <0xff' हमेशा सच होती है। OptionUtil.java (32)

public static final ByteSequence prefixEndOf(ByteSequence prefix) { byte[] endKey = prefix.getBytes().clone(); for (int i = endKey.length - 1; i >= 0; i--) { if (endKey[i] < 0xff) { // <= endKey[i] = (byte) (endKey[i] + 1); return ByteSequence.from(Arrays.copyOf(endKey, i + 1)); } } return ByteSequence.from(NO_PREFIX_END); } 

बाइट प्रकार का मान (-128 से 127 का मान) की तुलना 0xff (255) के मान से की जाती है। इस स्थिति में, यह ध्यान में नहीं रखा जाता है कि जावा में बाइट प्रकार पर हस्ताक्षर किए गए हैं, इसलिए स्थिति हमेशा सही होगी, जिसका अर्थ है कि यह अर्थहीन है।

उसी मूल्यों की वापसी

V6007 अभिव्यक्ति '.PreferIPV6Address ()' हमेशा झूठी है। NetUtils.java (236)

 private static Optional<InetAddress> toValidAddress(InetAddress address) { if (address instanceof Inet6Address) { Inet6Address v6Address = (Inet6Address) address; if (isPreferIPV6Address()) { // <= return Optional.ofNullable(normalizeV6Address(v6Address)); } } if (isValidV4Address(address)) { return Optional.of(address); } return Optional.empty(); } 

विधि .PreferIPV6Address है ।

 static boolean isPreferIPV6Address() { boolean preferIpv6 = Boolean.getBoolean("java.net.preferIPv6Addresses"); if (!preferIpv6) { return false; // <= } return false; // <= } 

ThePreferIPV6Address विधि दोनों मामलों में गलत है। सबसे अधिक संभावना है, एक डेवलपर चाहता था कि एक मामला सच हो, अन्यथा विधि का कोई मतलब नहीं है।

व्यर्थ की जाँच

V6007 अभिव्यक्ति '! मुखौटा [i]। असमानता (ipAddress [i])' हमेशा सच है। NetUtils.java (476)

 public static boolean matchIpRange(....) throws UnknownHostException { .... for (int i = 0; i < mask.length; i++) { if ("*".equals(mask[i]) || mask[i].equals(ipAddress[i])) { continue; } else if (mask[i].contains("-")) { .... } else if (....) { continue; } else if (!mask[i].equals(ipAddress[i])) { // <= return false; } } return true; } 

इस स्थिति में अगर-और-अगर, चेक "*"। बराबर (मुखौटा [i]) || मास्क [i] .equals (ipAddress [i]) किया जाता है। यदि शर्त पूरी नहीं होती है, तो अगला चेक अगर और-में होता है, जो हमें उस मास्क को दिखाता है [i] और ipAddress [i] समान नहीं हैं। लेकिन अगर-और-अगर यह निम्नलिखित चेकों में से किसी एक में है तो वह मास्क [i] और ipAddress [i] बराबर नहीं है। चूंकि मास्क [i] और ipAddress [i ] को कोई मान निर्दिष्ट नहीं किया गया है, दूसरा चेक व्यर्थ है।

V6007 अभिव्यक्ति 'message.length> 0' हमेशा सच होता है। डिप्रेस्डटेलनेटकोडे.जावा (302)

V6007 अभिव्यक्ति 'संदेश! = नल' हमेशा सच है। डिप्रेस्डटेलनेटकोडे.जावा (302)

 protected Object decode(.... , byte[] message) throws IOException { .... if (message == null || message.length == 0) { return NEED_MORE_INPUT; } .... // Here the variable <i>message </i> doesn't change! .... if (....) { String value = history.get(index); if (value != null) { byte[] b1 = value.getBytes(); if (message != null && message.length > 0) { // <= byte[] b2 = new byte[b1.length + message.length]; System.arraycopy(b1, 0, b2, 0, b1.length); System.arraycopy(message, 0, b2, b1.length, message.length); message = b2; } else { message = b1; } } } .... } 

चेक मैसेज! = Null && message.length> 0 लाइन 302 में बेमानी है। 302 पंक्ति में जाँच से पहले, निम्नलिखित जाँच की जाती है:

 if (message == null || message.length == 0) { return NEED_MORE_INPUT; } 

यदि चेक की शर्त पूरी नहीं होती है, तो हम जानेंगे कि संदेश शून्य नहीं है और इसकी लंबाई 0. के बराबर नहीं है। यह इस प्रकार है कि इसकी लंबाई 0 से अधिक है (स्ट्रिंग की लंबाई के रूप में एक नहीं हो सकता है नकारात्मक संख्या)। स्थानीय वैरिएबल संदेश को लाइन 302 से पहले कोई मान नहीं सौंपा गया है, जिसका अर्थ है लाइन 302 में संदेश चर का मान ऊपर दिए गए कोड के समान है। यह निष्कर्ष निकाला जा सकता है कि अभिव्यक्ति संदेश! = Null && message.length> 0 हमेशा सत्य होगा, लेकिन अन्य ब्लॉक में कोड कभी निष्पादित नहीं होगा।

एक Uninitialized संदर्भ फ़ील्ड का मान सेट करना

V6007 अभिव्यक्ति '! ShouldExport ()' हमेशा झूठी होती है। ServiceConfig.java (371)

 public synchronized void export() { checkAndUpdateSubConfigs(); if (!shouldExport()) { // <= return; } if (shouldDelay()) { .... } else { doExport(); } 

ServiceConfig वर्ग की shouldExport विधि getExport विधि को कॉल करती है, जिसे उसी कक्षा में परिभाषित किया गया है।

 private boolean shouldExport() { Boolean export = getExport(); // default value is true return export == null ? true : export; } .... @Override public Boolean getExport() { return (export == null && provider != null) ? provider.getExport() : export; } 

GetExport मेथड, Abstract AbstractServiceConfig क्लास के getExport मेथड को कॉल करता है, जो बूलियन टाइप के एक्सपोर्ट फील्ड का मान लौटाता है। फ़ील्ड मान सेट करने के लिए एक setExport विधि भी है।

 protected Boolean export; .... public Boolean getExport() { return export; } .... public void setExport(Boolean export) { this.export = export; } 

निर्यात क्षेत्र कोड में केवल setExport विधि द्वारा सेट किया गया है। SetExport विधि केवल एब्सट्रैक्ट AbstractServiceBuilder वर्ग के निर्माण विधि में कहा जाता है (केवल AbstractServiceConfig का विस्तार) यदि क्षेत्र शून्य नहीं है।

 @Override public void build(T instance) { .... if (export != null) { instance.setExport(export); } .... } 

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

परिणामस्वरूप, ServiceSonfig क्लास का getExport मेथड, AbstractServiceConfig क्लास का विस्तार करते हुए हमेशा वापस लौटेगा। रिटर्न वैल्यू का उपयोग ServiceConfig क्लास के shouldExport मेथड में किया जाता है, इसलिए shouldExport method हमेशा सही रहेगा। सच लौटने के कारण, की ! ShouldExport () अभिव्यक्ति का मूल्य हमेशा गलत होगा। यह पता चला है, कि ServiceConfig वर्ग का निर्यात क्षेत्र कभी भी वापस नहीं आएगा जब तक कि निम्नलिखित कोड निष्पादित नहीं किया जाता है:

 if (shouldDelay()) { DELAY_EXPORT_EXECUTOR.schedule(this::doExport, getDelay(), ....); } else { doExport(); } 

गैर-नकारात्मक पैरामीटर का मान

V6009 ' प्रतिस्थापन ' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। तर्क का निरीक्षण करें: 2. AbstractEtcdClient.java (169)

 protected void createParentIfAbsent(String fixedPath) { int i = fixedPath.lastIndexOf('/'); if (i > 0) { String parentPath = fixedPath.substring(0, i); if (categories.stream().anyMatch(c -> fixedPath.endsWith(c))) { if (!checkExists(parentPath)) { this.doCreatePersistent(parentPath); } } else if (categories.stream().anyMatch(c -> parentPath.endsWith(c))) { String grandfather = parentPath .substring(0, parentPath.lastIndexOf('/')); // <= if (!checkExists(grandfather)) { this.doCreatePersistent(grandfather); } } } } 

अंतिम IndexOf फ़ंक्शन का परिणाम दूसरे फ़ंक्शन के रूप में प्रतिस्थापित फ़ंक्शन के लिए दिया जाता है, जिसका दूसरा पैरामीटर एक ऋणात्मक संख्या नहीं होना चाहिए, भले ही lastIndexOf -1 वापस आ सकता है यदि यह स्ट्रिंग में मांग-के लिए मान नहीं पाता है। यदि सबस्ट्रिंग विधि का दूसरा पैरामीटर पहले (-1 <0) से कम है, तो अपवाद StringIndexOutOfBoundsException को फेंक दिया जाएगा। त्रुटि को ठीक करने के लिए, हमें अंतिम IndexOf फ़ंक्शन द्वारा लौटाए गए परिणाम की जांच करने की आवश्यकता है। यदि यह सही है (कम से कम, नकारात्मक नहीं), तो इसे प्रतिस्थापन फ़ंक्शन में पास करें।

अप्रयुक्त लूप काउंटर

V6016 लूप के अंदर एक स्थिर सूचकांक द्वारा 'प्रकार' ऑब्जेक्ट के तत्व तक संदिग्ध पहुंच। RpcUtils.java (153)

 public static Class<?>[] getParameterTypes(Invocation invocation) { if ($INVOKE.equals(invocation.getMethodName()) && invocation.getArguments() != null && invocation.getArguments().length > 1 && invocation.getArguments()[1] instanceof String[]) { String[] types = (String[]) invocation.getArguments()[1]; if (types == null) { return new Class<?>[0]; } Class<?>[] parameterTypes = new Class<?>[types.length]; for (int i = 0; i < types.length; i++) { parameterTypes[i] = ReflectUtils.forName(types[0]); // <= } return parameterTypes; } return invocation.getParameterTypes(); } 

लूप के लिए , सरणी प्रकार के तत्व तक पहुंचने के लिए एक 0 निरंतर सूचकांक का उपयोग किया जाता है। यह सरणी तत्वों तक पहुँचने के लिए एक सूचकांक के रूप में i चर का उपयोग करने के लिए किया गया हो सकता है। लेकिन लेखकों ने इसे छोड़ दिया है।

व्यर्थ करते-करते

V6019 अनुपलब्ध कोड का पता चला। यह संभव है कि कोई त्रुटि मौजूद हो। ग्रिज़्ली कोडेक एडेप्टर। जावा (136)

 @Override public NextAction handleRead(FilterChainContext context) throws IOException { .... do { savedReadIndex = frame.readerIndex(); try { msg = codec.decode(channel, frame); } catch (Exception e) { previousData = ChannelBuffers.EMPTY_BUFFER; throw new IOException(e.getMessage(), e); } if (msg == Codec2.DecodeResult.NEED_MORE_INPUT) { frame.readerIndex(savedReadIndex); return context.getStopAction(); } else { if (savedReadIndex == frame.readerIndex()) { previousData = ChannelBuffers.EMPTY_BUFFER; throw new IOException("Decode without read data."); } if (msg != null) { context.setMessage(msg); return context.getInvokeAction(); } else { return context.getInvokeAction(); } } } while (frame.readable()); // <= .... } 

लूप की स्थिति में अभिव्यक्ति करते हैं - जबकि (फ्रेम.ड्रेडेबल ()) अगम्य कोड है, क्योंकि लूप के पहले पुनरावृत्ति के दौरान विधि बाहर निकलती है। अगर-का उपयोग करते हुए लूप के शरीर में msg चर की कई जांचें की जाती हैं। ऐसा करने में, यदि दोनों में और अन्य मूल्यों को विधि से वापस कर दिया जाता है या अपवाद फेंक दिया जाता है। यही कारण है कि लूप का शरीर केवल एक बार निष्पादित होता है, इसलिए इस लूप के उपयोग का कोई मतलब नहीं है।

कॉपी-पेस्ट स्विच में

V6067 दो या दो से अधिक केस-शाखाएँ एक ही क्रिया करते हैं। JVMUtil.java (67), JVMUtil.java (71)

 private static String getThreadDumpString(ThreadInfo threadInfo) { .... if (i == 0 && threadInfo.getLockInfo() != null) { Thread.State ts = threadInfo.getThreadState(); switch (ts) { case BLOCKED: sb.append("\t- blocked on " + threadInfo.getLockInfo()); sb.append('\n'); break; case WAITING: // <= sb.append("\t- waiting on " + threadInfo.getLockInfo()); // <= sb.append('\n'); // <= break; // <= case TIMED_WAITING: // <= sb.append("\t- waiting on " + threadInfo.getLockInfo()); // <= sb.append('\n'); // <= break; // <= default: } } .... } 

WAITING और TIMED_WAITING मामलों के लिए कोड में कॉपी-पेस्ट कोड होता है। यदि समान कार्य किए जाने हैं, तो WAITING केस ब्लॉक की सामग्री को हटाकर कोड को सरल बनाया जा सकता है। परिणामस्वरूप, वही कोड WAITING और TIMED_WAITING के लिए निष्पादित किया जाएगा ।

निष्कर्ष

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

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

इस तरह के एक अद्भुत उपकरण के लिए Apache Dubbo Developers का धन्यवाद। मुझे उम्मीद है कि यह लेख आपको कोड को बेहतर बनाने में मदद करेगा। लेख कोड के सभी संदिग्ध टुकड़ों का वर्णन नहीं करता है, इसलिए यह डेवलपर्स के लिए सबसे अच्छा है कि वे स्वयं परियोजना की जांच करें और परिणामों का मूल्यांकन करें।