PVS-Studio स्थैतिक विश्लेषक के साथ Apache Dubbo फ्रेमवर्क के RPC स्रोत कोड का विश्लेषण

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

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

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

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

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

अपाचे डब्बू: यह क्या है और यह क्या खाता है?

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

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

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

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

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

विश्लेषण के परिणाम: उच्च और मध्यम आत्मविश्वास के स्तर (क्रमशः और 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(); } 

IsPreferIPV6Address विधि।

 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; } 

If-else-if की स्थितियों में सबसे पहले, एक "*" चेक होता है । बराबर (मुखौटा [i]) || मुखौटा [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; } .... //   message  ! .... 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; } } } .... } 

संदेश की जाँच करना ! = 302 लाइन पर Null && message.length> 0 का कोई मतलब नहीं है। चेक से पहले, लाइन 302 चेक:

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

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

एक असंवैधानिक संदर्भ फ़ील्ड का मान सेट करना

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 विधि, 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 Method, AbstractServiceConfig क्लास को एक्सटेंड करने वाला हमेशा सुस्त रहेगा। लौटाया गया मूल्य ServiceConfig वर्ग के shouldExport विधि में उपयोग किया जाता है, इसलिए shouldExport विधि हमेशा सही लौटेगी। सच लौटने के कारण, अभिव्यक्ति का मूल्य ! 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); } } } } 

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

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

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 का उपयोग करता है। शायद यह सरणी के तत्वों का उपयोग करने के लिए एक सूचकांक के रूप में चर का उपयोग करने के लिए था, लेकिन वे कहते हैं कि अनदेखी नहीं की थी।

अर्थहीन करते-करते

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 के लिए निष्पादित किया जाएगा।

निष्कर्ष

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

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

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

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