2012-02-08 19 views
6

संभव डुप्लिकेट:
Is there any performance reason to declare method parameters final in Java?
Why would one mark local variables and method parameters as “final” in Java?जावा: क्यों स्थानीय चर अंतिम घोषित किया जाना चाहिए

मैं PMD उपयोग कर रहा हूँ संहिता के उल्लंघन को देखने के लिए।

एक वेब सेवा विधि के अंदर, मैं कोड

public ServiceRequest getData() 
{ 
Status status = new Status(); 
// code 
} 

क्या PMD मुझे सुझाव दे रहा है नीचे इस है, इस स्थानीय चर स्थिति का अंतिम रूप में घोषित किया जा सकता है।

मेरा सवाल यह है कि इसे अंतिम बनाने के परिणामस्वरूप कोई प्रदर्शन सुधार होगा या कोड को क्या लाभ नहीं मिलेगा?

+0

http://stackoverflow.com/a/266981/259576 –

+0

का डुप्लिकेट जैसा कि [स्टैक ओवरफ्लो उत्तरों] में वर्णित है (http://stackoverflow.com/questions/316352/why-would-one-mark-local-variables -और-विधि-पैरामीटर-जैसे-फाइनल-इन-जावा) कंपाइलर बेहतर प्रदर्शन के लिए अनुकूलित कोड का उत्पादन कर सकता है। – ChangeRequest

+0

कृपया एक * एकल * अनुकूलन का वर्णन करें जो केवल तभी संभव हो जब स्थानीय चर को अंतिम घोषित किया जाता है - क्योंकि मैं निश्चित रूप से किसी के बारे में नहीं सोच सकता और मैं आपके लिंक में वर्णित किसी को भी नहीं देख सकता। – Voo

उत्तर

1

मुझे स्टेटस फाइनल बनाकर प्रदर्शन-लाभ के बारे में पता नहीं है, लेकिन पीएमडी आपको यह सुझाव दे रहा है, क्योंकि शायद आप इसकी पहली शुरुआत के बाद कभी भी स्थिति पर लिख नहीं रहे हैं।

तो तुम यह अंतिम बनाकर क्या लाभ सिर्फ इतना है कि अपने कोड त्रुटि-रहित होता है है - अगर आप की घोषणा यह अंतिम, तुम नहीं कर सकते यह गलती से ऊपर लिख ...

4

निम्न आलेख से लिया: http://www.javapractices.com/topic/TopicAction.do?Id=23

  • स्पष्ट रूप से अपनी मंशा
  • संकलक और आभासी मशीन मामूली अनुकूलन
  • स्पष्ट रूप से झंडे आइटम जो व्यवहार में सरल हैं करने की अनुमति देता संचार - अंतिम कहते हैं, "आप देख रहे हैं कंप्यूटर अनुप्रयोग के लिए लापरवाही, आपको यह यहां नहीं मिलेगा। "

यह भी इस सवाल में चर्चा की है: Can excessive use of final hurt more than do good?

+1

'संकलक और आभासी मशीन को मामूली अनुकूलन करने की अनुमति देता है' - वास्तव में नहीं, वास्तव में नहीं। यह किस प्रकार का अनुकूलन होगा? – Voo

+2

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

+0

जेवाक जेनरेट बाइटकोड एन्कोड नहीं करता है कि एक चर अंतिम है। जेआईटी को कोई जानकारी नहीं है कि चर एक बार अंतिम था। –

4

final इंगित करता है स्थानीय चर बदला नहीं जाएगा। मेरी भावना यह है कि विधियों को इतना छोटा होना चाहिए कि आप उन्हें आसानी से समझने में सक्षम होना चाहिए और इसलिए परिवर्तनीय अंतिम बनाना थोड़ा अनावश्यक हो सकता है।

मैं फ़ील्ड final बनाना पसंद करता हूं क्योंकि पूरी कक्षा इतनी छोटी है, एक गंभीर सीमा है। इसके अलावा फ़ील्ड में थ्रेड सुरक्षा समस्याएं हो सकती हैं जो स्थानीय चर नहीं करते हैं।

+0

मैं सहमत हूं। अंतिम स्थानीय लोगों का उपयोग करने का एकमात्र कारण यह है कि अनाम कक्षाओं का उपयोग करते समय (लेकिन तब भी नहीं क्योंकि मैं ** ** चाहता हूं)। और मुझे दावा किए गए प्रदर्शन लाभों पर संदेह है - मुझे नहीं पता कि हम वहां कौन सी अतिरिक्त जानकारी प्राप्त करते हैं। – Voo

+0

जेआईटी चरम पर काम करने के लिए पर्याप्त स्मार्ट है प्रभावी रूप से अंतिम है, इसलिए मुझे संदेह है कि यह प्रदर्शन में काफी सुधार करता है। 'जावैक' कंपाइलर को एक वैरिएबल को काम करने के लिए पर्याप्त स्मार्ट होना चाहिए, प्रभावी रूप से अंतिम (यानी कभी नहीं बदला गया) और अज्ञात वर्गों IMHO के लिए इसकी आवश्यकता नहीं है। 'अंतिम' चर बड़े जटिल तरीकों में उपयोगी होते हैं, लेकिन वास्तविक समाधान आपके कोड को फिर से कारक बनाना है ताकि आपके पास बड़ी जटिल विधियां न हों। ;) –

+1

चूंकि हमारे पास जावा में संदर्भ नहीं हैं, इसलिए मैं नहीं देखता कि कोड किसी भी तरह से अंतिम परिवर्तन कैसे करता है। ध्यान दें: 'int x = 10', x तब तक 10 होगा जब तक हम विधि के अंदर xa new value * असाइन नहीं करते हैं * (ठीक है कंपाइलर/जेआईटी को यह जांचना है कि हम ऐसा नहीं करते हैं, लेकिन यह है जांच करने के लिए स्पष्ट)। हाँ फाइनल अन्य प्रोग्रामर के लिए उपयोगी हो सकता है, लेकिन फिर हम सभी सहमत हैं कि यदि एक विधि लंबी और जटिल है कि हम एक नज़र में सभी परिवर्तनीय असाइनमेंट नहीं देखते हैं तो हमारे पास बहुत बड़ी समस्या है;) – Voo

संबंधित मुद्दे