त्रुटि java.lang.OutOfMemoryError: GC ओवरहेड सीमा पार हो गई है

804

मुझे यह त्रुटि संदेश मिलता है क्योंकि मैं अपने JUnit परीक्षण निष्पादित करता हूं:

java.lang.OutOfMemoryError: GC overhead limit exceeded

मुझे पता है कि क्या OutOfMemoryErrorहै, लेकिन जीसी ओवरहेड सीमा का क्या मतलब है? इसे कैसे हल किया जा सकता है?

java  garbage-collection  out-of-memory  heap-memory 
— Mnementh
स्रोत
16
यह बहुत दिलचस्प लगता है। अगर कोई ऐसा कोड जनरेट करता है, तो मुझे अच्छा लगेगा।
— बुहब
1
मुझे बस समस्या मिली, कि ढेर की सीमा के पास बहुत अधिक मेमोरी-उपयोग हो रहा है। एक सरल समाधान केवल जावा-इंजन (-Xmx) को कुछ और हीप-मेमोरी देने के लिए हो सकता है, लेकिन यह केवल तभी मदद करता है, जब एप्लिकेशन को ठीक से अधिक मेमोरी की आवश्यकता होती है, जैसा कि पहले निर्धारित किया गया था।
— मेन्मेन्थ
1
@ मेन्मेंट ने मुझे यहाँ एक उत्तर दिया था कि जाँच करें कि क्या यह stackoverflow.com/questions/11091516/… को
— lulu
16
@SimonKuang ध्यान दें कि ऐसे कई OutOfMemoryErrorपरिदृश्य हैं जिनके लिए हीप को बढ़ाना एक वैध समाधान नहीं है: देशी थ्रेड्स से बाहर निकलना और परमिट जीन (जो ढेर से अलग है) से बाहर निकलना दो उदाहरण हैं। के बारे में अधिक व्यापक बयान करने के बारे में सावधान रहें OutOfMemoryErrors; वहाँ अप्रत्याशित रूप से विविध चीजें हैं जो उन्हें पैदा कर सकती हैं।
— टिम
3
आपने मसला कैसे हल किया ??
— थोरस्टेन नेह्यूस

जवाबों:

763

इस संदेश का अर्थ है कि किसी कारण से कचरा संग्रहकर्ता अत्यधिक समय ले रहा है (प्रक्रिया के सभी सीपीयू समय के डिफ़ॉल्ट रूप से ९ some%) और प्रत्येक रन में बहुत कम मेमोरी पुनर्प्राप्त करता है (डिफ़ॉल्ट रूप से ढेर का २%)।

इसका प्रभावी रूप से मतलब है कि आपका कार्यक्रम किसी भी प्रगति को करना बंद कर देता है और हर समय केवल कचरा संग्रह चलाने में व्यस्त रहता है।

आपके एप्लिकेशन को कुछ भी किए बिना सीपीयू समय को भिगोने से रोकने के लिए, जेवीएम इसे फेंकता है Errorताकि आपके पास समस्या का निदान करने का मौका हो।

जिन दुर्लभ मामलों में मैंने यह देखा है, वह यह है कि कुछ कोड अस्थायी वस्तुओं का टन बना रहे थे और पहले से ही बहुत स्मृति-बाधित वातावरण में कमजोर-संदर्भित वस्तुओं के टन।

जावा GC ट्यूनिंग गाइड देखें, जो विभिन्न जावा संस्करणों के लिए उपलब्ध है और इसमें इस विशिष्ट समस्या के बारे में अनुभाग हैं:

— जोआचिम सौअर
स्रोत
9
क्या आपके उत्तर को संक्षेप में प्रस्तुत करना सही होगा: "यह 'आउट ऑफ जावा हीप स्पेस' त्रुटि जैसा है। इसे -Xmx के साथ अधिक मेमोरी दें।" ?
— टिम कूपर
58
@ समय: नहीं, यह सही नहीं होगा। इसे अधिक मेमोरी देने से समस्या कम हो सकती है, आपको अपने कोड को भी देखना चाहिए और यह देखना चाहिए कि यह कचरे की मात्रा क्यों पैदा करता है और "कोड ऑफ मेमोरी" निशान के ठीक नीचे क्यों कोड होता है। यह अक्सर टूटे हुए कोड का संकेत है।
— जोकिम सॉयर
8
धन्यवाद, ऐसा लगता है कि Oracle वास्तव में डेटा माइग्रेशन में उतना अच्छा नहीं है, उन्होंने लिंक को तोड़ दिया।
— जोआचिम सॉउर
151
आपने मुझे "धन्यवाद, ऐसा लगता है कि ओरेकल वास्तव में उतना अच्छा नहीं है"
— रोब ग्रांट
3
@ ग्यूस: यदि कई एप्लिकेशन एक ही JVM में चलते हैं, तो हाँ, वे एक दूसरे को आसानी से प्रभावित कर सकते हैं। यह बताना मुश्किल होगा कि कौन सा दुर्व्यवहार कर रहा है। अलग-अलग JVM में अनुप्रयोगों को अलग करना सबसे आसान समाधान हो सकता है।
— जोकिम सॉर
215

ओरेकल के लेख से हवाला देते हुए "जावा SE 6 हॉटस्पॉट [टीएम] वर्चुअल मशीन कूड़ा संग्रह ट्यूनिंग" :

अत्यधिक जीसी समय और आउटऑफ़मेरीऑयर

समानांतर कलेक्टर एक OutOfMemoryError को फेंक देगा यदि बहुत अधिक समय कचरा संग्रह में खर्च किया जा रहा है: यदि कुल समय का 98% से अधिक समय कचरा संग्रह में खर्च किया जाता है और 2% से कम हीप बरामद किया जाता है, तो एक OutffememoryError फेंक दिया जाएगा। यह सुविधा अनुप्रयोगों को कम या कोई प्रगति नहीं करते हुए विस्तारित अवधि के लिए चलने से रोकने के लिए डिज़ाइन की गई है क्योंकि ढेर बहुत छोटा है। यदि आवश्यक हो, -XX:-UseGCOverheadLimitतो कमांड लाइन के विकल्प को जोड़कर इस सुविधा को अक्षम किया जा सकता है ।

संपादित करें: ऐसा लगता है कि कोई मुझसे तेज टाइप कर सकता है :)

— डेव
स्रोत
87
"आप इसे बंद कर सकते हैं ..." लेकिन ओपी सबसे अधिक संभावना यह नहीं करना चाहिए।
— स्टीफन सी
2
क्या आप मुझे "-XX" और "-Xmx" के बीच का अंतर बता सकते हैं? मैं "-Xmx" विकल्प का उपयोग करके इसे बंद करने में सक्षम था।
— सुशील जावड़ी
19
यहां बहुत पुरानी टिप्पणी का जवाब दिया जा रहा है, लेकिन ... @ बर्ट -XX:कई कमांड लाइन विकल्पों की शुरुआत में यह दर्शाता है कि यह विकल्प अत्यधिक वीएम-विशिष्ट और अस्थिर है (भविष्य के संस्करणों में सूचना के बिना परिवर्तन के अधीन)। किसी भी स्थिति में, -XX:-UseGCOverheadLimitध्वज वीएम को जीसी ओवरहेड लिमिट चेकिंग को अक्षम करने के लिए कहता है (वास्तव में "इसे बंद कर देता है"), जबकि आपकी -Xmxकमांड ने केवल ढेर बढ़ा दिया है। बाद के मामले में जीसी ओवरहेड चेकिंग अभी भी चल रही थी , यह सिर्फ एक बड़े ढेर की तरह लगता है जो आपके मामले में जीसी थ्रशिंग मुद्दों को हल करता है (यह हमेशा मदद नहीं करेगा)।
— आंद्रेज डॉयल
1
मेरे आवेदन में (टैलेंड में एक बड़ी एक्सेल फाइल पढ़ते हुए) यह काम नहीं किया और अन्य उपयोगकर्ताओं के स्पष्टीकरण से मुझे समझ में आया कि क्यों। यह सिर्फ त्रुटि को अक्षम करता है लेकिन समस्या बनी रहती है और आपका आवेदन जीसी को संभालने में अपना अधिकांश समय व्यतीत करेगा। हमारे सर्वर में भरपूर रैम थी इसलिए मैंने ढेर के आकार को बढ़ाने के लिए विटालि के सुझावों का इस्तेमाल किया।
— रॉबज
आपको अंततः यह त्रुटि मिलेगी यदि आपका एप्लिकेशन डेटा गहन है, तो मेमोरी साफ़ करना और डेटा लीक करना सबसे अच्छा तरीका है - लेकिन इसके लिए कुछ समय चाहिए।
— 16
89

यदि आप सुनिश्चित हैं कि आपके कार्यक्रम में कोई मेमोरी लीक नहीं है , तो प्रयास करें:

  1. उदाहरण के लिए, ढेर का आकार बढ़ाएँ -Xmx1g।
  2. समवर्ती कम ठहराव कलेक्टर सक्षम करें -XX:+UseConcMarkSweepGC।
  3. कुछ यादों को सहेजने के लिए जब संभव हो मौजूदा वस्तुओं का पुन: उपयोग करें।

यदि आवश्यक हो, तो कमांड लाइन के विकल्प को जोड़कर सीमा की जांच को अक्षम किया जा सकता है -XX:-UseGCOverheadLimit।

— विटाली फेडोरेंको
स्रोत
9
मैं तीसरी सलाह से असहमत हूं। मौजूदा वस्तुओं का पुन: उपयोग स्मृति को नहीं बचाता है (पुरानी वस्तुओं को लीक न करें याददाश्त बचाएं :-) इसके अलावा जीसी दबाव को राहत देने के लिए "मौजूदा वस्तु का पुन: उपयोग करें" एक अभ्यास था। लेकिन यह हमेशा एक अच्छा विचार नहीं है: आधुनिक जीसी के साथ, हमें उन परिस्थितियों से बचना चाहिए जहां पुरानी वस्तुएं नई
— पकड़ती
@mcoolive: कुछ विपरीत उदाहरण के लिए, नीचे stackoverflow.com/a/5640498/4178262 जवाब देने के लिए टिप्पणियां देखें; Listलूप के अंदर वस्तु बनाने के कारण जीसी को 22 बार के बजाय 39 गुना कहा जाता है।
— मार्क स्टीवर्ट
45

यह आमतौर पर कोड है। यहाँ एक सरल उदाहरण दिया गया है:

import java.util.*;

public class GarbageCollector {

    public static void main(String... args) {

        System.out.printf("Testing...%n");
        List<Double> list = new ArrayList<Double>();
        for (int outer = 0; outer < 10000; outer++) {

            // list = new ArrayList<Double>(10000); // BAD
            // list = new ArrayList<Double>(); // WORSE
            list.clear(); // BETTER

            for (int inner = 0; inner < 10000; inner++) {
                list.add(Math.random());
            }

            if (outer % 1000 == 0) {
                System.out.printf("Outer loop at %d%n", outer);
            }

        }
        System.out.printf("Done.%n");
    }
}

विंडोज 7 32 बिट पर जावा 1.6.0_24-b07 का उपयोग करना।

java -Xloggc:gc.log GarbageCollector

फिर देखो gc.log

  • BAD विधि का उपयोग करके 444 बार ट्रिगर किया गया
  • कार्य विधि का उपयोग करके 666 बार ट्रिगर किया गया
  • बेहतर 354 बार ट्रिगर विधि का उपयोग कर

अब दी गई, यह सबसे अच्छा परीक्षण या सबसे अच्छा डिज़ाइन नहीं है, लेकिन जब ऐसी स्थिति का सामना करना पड़ता है, जहां आपके पास कोई विकल्प नहीं है, तो ऐसे लूप को लागू करना या मौजूदा कोड से निपटना, जो बुरी तरह से व्यवहार करता है, नए बनाने के बजाय वस्तुओं का पुन: उपयोग करना चुन सकता है। कचरा इकट्ठा करने वाले को रास्ते में जितनी बार ...

— माइक
स्रोत
12
कृपया स्पष्ट करें: जब आप "ट्रिगर किए गए n बार" कहते हैं, तो क्या इसका मतलब यह है कि नियमित जीसी एन बार हुआ, या ओपी द्वारा रिपोर्ट की गई "जीसी ओवरहेड सीमा पार हो गई" त्रुटि एन बार हुई?
— जॉन श्नाइडर
मैंने अभी जावा 1.8.0_91 का उपयोग करके परीक्षण किया और कभी भी कोई त्रुटि / अपवाद नहीं मिला, और "ट्रिगर n समय" gc.logफ़ाइल में लाइनों की संख्या की गिनती से था । मेरे परीक्षण कुल मिलाकर बहुत कम समय दिखाते हैं, लेकिन अब तक के सबसे कम "ट्रिगर" बार, और अब, BAD काम से "बदमाश" है। मेरी गिनती: BAD: 26, WORSE: 22, बेहतर 21.
— मार्क स्टीवर्ट
मैं सिर्फ एक "WORST_YET" संशोधन जहाँ मैं परिभाषित जोड़ा List<Double> listमें बाहरी पाश के बजाय पहले बाहरी पाश, और 39 कचरा संग्रह उत्प्रेरित।
— मार्क स्टीवर्ट
36

जावा [8] प्लेटफॉर्म के अनुसार त्रुटि का कारण , मानक संस्करण समस्या निवारण गाइड : (जोर और लाइन टूट गयी)

[...] "जीसी ओवरहेड सीमा पार हो गई" इंगित करता है कि कचरा कलेक्टर हर समय चल रहा है और जावा कार्यक्रम बहुत धीमी प्रगति कर रहा है।

एक कचरा संग्रह के बाद, यदि जावा प्रक्रिया अपना लगभग 98% से अधिक समय कचरा संग्रह करने में खर्च कर रही है और यदि यह 2% से भी कम समय में ठीक हो रही है और अब तक पिछले 5 (संकलन समय स्थिर) लगातार कचरा कर रही है संग्रह, फिर एक java.lang.OutOfMemoryErrorफेंक दिया जाता है। [...]

  1. यदि वर्तमान हीप पर्याप्त नहीं है, तो हीप आकार बढ़ाएँ ।
  2. यदि आप ढेर मेमोरी बढ़ाने के बाद भी यह त्रुटि प्राप्त करते हैं, तो MAT (मेमोरी एनालाइज़र टूल), विज़ुअल वीएम आदि जैसे मेमोरी प्रोफाइलिंग टूल का उपयोग करें और मेमोरी लीक को ठीक करें।
  3. JDK संस्करण को नवीनतम संस्करण (1.8.x) या कम से कम 1.7.x पर अपग्रेड करें और G1GC एल्गोरिदम का उपयोग करें। । जी 1 जीसी के लिए थ्रूपुट लक्ष्य 90 प्रतिशत आवेदन समय और 10 प्रतिशत कचरा संग्रह समय है

  4. इसके साथ हीप मेमोरी को सेट करने के अलावा - Xms1g -Xmx2gप्रयास करें

    -XX:+UseG1GC -XX:G1HeapRegionSize=n -XX:MaxGCPauseMillis=m  
-XX:ParallelGCThreads=n -XX:ConcGCThreads=n

G1GC से संबंधित कुछ और सवालों पर एक नजर

— रवींद्र बाबू
स्रोत
29

इस विकल्प को सेट करके बस ढेर का आकार थोड़ा बढ़ाएँ

रन → रन कॉन्फ़िगरेशन → तर्क → वीएम तर्क

-Xms1024M -Xmx2048M

Xms - न्यूनतम सीमा के लिए

Xmx - अधिकतम सीमा के लिए

— chopss
स्रोत
2
Android ऐप्स में argumentsटैब नहीं है ... इसे प्राप्त करने के लिए हमें क्या करना चाहिए?
— ब्लेज़ तम
3
उस उत्तर के लिए कौन सा उपकरण है? यह एक ग्रहण प्रश्न नहीं था।
— माइकल पिफेल
3
कोई "न्यूनतम सीमा" नहीं है। -Xms प्रारंभिक आकार है।
— डिएगो क्विरोज़
1
अधिकतम सीमा क्या है जो सेट की जा सकती है ??
— जेपीकेर
14

मेरे लिए, निम्न चरणों ने काम किया:

  1. eclipse.iniफ़ाइल खोलें

  2. परिवर्तन

    -Xms40m
-Xmx512m

    सेवा

    -Xms512m
-Xmx1024m

  3. ग्रहण को पुनः आरंभ करें

यहाँ देखें

— सुनील कुमार साहू
स्रोत
इस समस्या को ठीक करने का सबसे सरल तरीका। धन्यवाद :)
— हमजा
1
eclipse.ini jdev में फाइल?
— अभिनबा बसु
कॉन्फ़िगरेशन के इसे बदल दिए जाने पर भी समस्याएँ अनसुलझी हैं।
— जियोनी
1
ओपी ने एक ग्रहण प्रश्न नहीं पूछा।
— माइकल पिफेल
1
यह "उत्तर" ऊपर दिए गए प्रश्न का उत्तर नहीं देता है।
— फ्रीटैग्स
13

इसे इस्तेमाल करे

build.gradleफ़ाइल खोलें

  android {
        dexOptions {
           javaMaxHeapSize = "4g"
        }
   }
— alicanozkara
स्रोत
सिम्युलेटर के लिए महान काम करता है। किसी भी विचार यह कैसे वास्तविक उपकरणों को प्रभावित करता है? यानी यह एक अच्छा विचार है या यह सिर्फ इस मुद्दे पर काम कर रहा है? धन्यवाद।
— जोशुआ पिंटर
11

निम्नलिखित ने मेरे लिए काम किया। बस निम्नलिखित स्निपेट जोड़ें:

android {
        compileSdkVersion 25
        buildToolsVersion '25.0.1'

defaultConfig {
        applicationId "yourpackage"
        minSdkVersion 10
        targetSdkVersion 25
        versionCode 1
        versionName "1.0"
        multiDexEnabled true
    }
dexOptions {
        javaMaxHeapSize "4g"
    }
}
— Hoshouns
स्रोत
हां, ग्रेडेल का उपयोग करते समय :)
— एलेक्स
4
आप यह भी कैसे सोच सकते हैं कि यह सामान्य रूप से उनके प्रश्न का समाधान है ? आप अपने ढेर के आकार को 4g पर सेट करते हैं जो कि एंड्रॉइड फेसपालम के लिए एक ग्रेड विन्यास में पूरी तरह से मनमाना है ।
— जूलियन एल।
7

javaMaxHeapsize को अपनी build.gradle (मॉड्यूल: ऐप) फ़ाइल में बढ़ाएं

dexOptions {
    javaMaxHeapSize "1g"
}

, (इस लाइन को gradle में जोड़ें)

 dexOptions {
        javaMaxHeapSize "4g"
    }
— साई गोपी एन
स्रोत
3

जावा हीप आकार विवरण (xms, xmx, xmn)

-Xms size in bytes

Example : java -Xms32m

जावा हीप का प्रारंभिक आकार सेट करता है। डिफ़ॉल्ट आकार 2097152 (2MB) है। मान 1024 बाइट्स (1KB) से अधिक और एक से अधिक होना चाहिए। (-Server ध्वज डिफ़ॉल्ट आकार को 32M तक बढ़ाता है।)

-Xmn size in bytes

Example : java -Xmx2m

ईडन पीढ़ी के लिए प्रारंभिक जावा हीप आकार सेट करता है। डिफ़ॉल्ट मान 640K है। (-Server ध्वज डिफ़ॉल्ट आकार को 2M तक बढ़ाता है।)

-Xmx size in bytes

Example : java -Xmx2048m

अधिकतम आकार सेट करता है जिससे जावा ढेर बढ़ सकता है। डिफ़ॉल्ट आकार 64M है। (-Server ध्वज डिफ़ॉल्ट आकार को 128M तक बढ़ाता है।) अधिकतम हीप सीमा लगभग 2 GB (2048MB) है।

जावा मेमोरी तर्क (xms, xmx, xmn) स्वरूपण

जावा हीप आकार सेट करते समय, आपको एमबी के लिए "एम" या "एम", या जीबी के लिए "जी" या "जी" अक्षरों में से एक का उपयोग करके अपने मेमोरी तर्क को निर्दिष्ट करना चाहिए। यदि आप "MB" या "GB" निर्दिष्ट करते हैं तो आपकी सेटिंग काम नहीं करेगी। मान्य तर्क इस तरह दिखते हैं:

-Xms64m या -Xms64M -Xmx1g या -Xmx1G 2GB को निर्दिष्ट करने के लिए 2048MB का भी उपयोग कर सकते हैं। यह भी सुनिश्चित करें कि आप अपने तर्कों को निर्दिष्ट करते समय केवल पूरे नंबरों का उपयोग करें। -Xmx512m का उपयोग करना एक वैध विकल्प है, लेकिन -Xmx0.5g एक त्रुटि का कारण होगा।

यह संदर्भ किसी के लिए मददगार हो सकता है।

— अचंभा
स्रोत
2

आप इसे अपनी gradle.propertiesफ़ाइल में जोड़कर मेमोरी आवंटन और ढेर का आकार भी बढ़ा सकते हैं :

org.gradle.jvmargs=-Xmx2048M -XX\:MaxHeapSize\=32g

यह 2048M और 32g होना जरूरी नहीं है, इसे उतना बड़ा बनाएं जितना आप चाहते हैं।

— जॉन डो
स्रोत
2

हल:
बस जोड़ने
org.gradle.jvmargs=-Xmx1024m
में
gradle.properties
और अगर यह मौजूद नहीं है, यह पैदा करते हैं।

— reza_khalafi
स्रोत
0

मैं एंड्रॉइड स्टूडियो में काम कर रहा हूं और इस त्रुटि का सामना करना पड़ा जब रिलीज के लिए एक हस्ताक्षरित APK बनाने की कोशिश कर रहा था। मैं एक डिबग एपीके का निर्माण और परीक्षण करने में सक्षम था, बिना किसी समस्या के, लेकिन जैसे ही मैं एक रिलीज एपीके का निर्माण करना चाहता था, निर्माण की प्रक्रिया अंत तक मिनटों तक चलेगी और फिर अंत में "त्रुटि java.lang.OutOfMemorError: GC के साथ समाप्त होगी। ओवरहेड सीमा पार हो गई ”। मैंने VM और Android DEX कंपाइलर दोनों के लिए ढेर के आकार में वृद्धि की, लेकिन समस्या बनी रही। अंत में, कई घंटों और कॉफी के मग के बाद यह पता चला कि समस्या मेरे ऐप-लेवल 'build.gradle' फ़ाइल में थी - मेरे पास रिलीज़ के लिए 'minifyEnabled' पैरामीटर था, जो 'गलत' के लिए सेट टाइप टाइप था, जिसके परिणामस्वरूप प्रोपर स्टफ चल रहे हैं। कोड पर जो कोड-सिकुड़ने की प्रक्रिया के माध्यम से नहीं हुआ है (देखें) https://developer.android)।)। मैंने 'minifyEnabled' पैरामीटर को 'true' में बदल दिया और रिलीज़ बिल्ड को एक सपने की तरह निष्पादित किया गया :)

संक्षेप में, मुझे अपने एप्लिकेशन-स्तर 'build.gradle' फ़ाइल को: // ... से बदलना होगा

buildTypes {
    release {
        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...

सेवा

    //...

buildTypes {
    release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        signingConfig signingConfigs.sign_config_release
    }
    debug {
        debuggable true
        signingConfig signingConfigs.sign_config_debug
    }
}

//...
— एलेक्स इवान हावर्ड
स्रोत
0

IntelliJ IDEA में ढेर का आकार बढ़ाने के लिए निम्नलिखित निर्देशों का पालन करें। इसने मेरे लिए काम किया।

विंडोज उपयोगकर्ताओं के लिए,

उस स्थान पर जाएं जहां आईडीई स्थापित है और निम्नलिखित के लिए खोज करें।

idea64.exe.vmoptions

फ़ाइल को संपादित करें और निम्नलिखित जोड़ें।

-Xms512m
-Xmx2024m
-XX:MaxPermSize=700m
-XX:ReservedCodeCacheSize=480m

बस इतना ही !!

— दुलिथ दे कोस्टा
स्रोत
0

आप इस छवि का संदर्भ देकर सर्वर सेटिंग में परिवर्तन करने की कोशिश कर सकते हैं और प्रसंस्करण प्रक्रिया परिवर्तनों के लिए मेमोरी का आकार बढ़ा सकते हैं

आप set _java_opts -Xmx2g
अपने प्रोग्राम की जटिलता के आधार पर cmd-> 2g (2gigabytes) खोलकर जावा हीप में बदलाव कर सकते हैं।

कम निरंतर चर और अस्थायी चर का उपयोग करने का प्रयास करें

यहां छवि विवरण दर्ज करें

— राहुल जैन
स्रोत
-1

आपको Jdeveloper में मेमोरी का आकार बढ़ाने के लिए setDomainEnv.cmd पर जाने की आवश्यकता है ।

set WLS_HOME=%WL_HOME%\server    
set XMS_SUN_64BIT=**256**
set XMS_SUN_32BIT=**256**
set XMX_SUN_64BIT=**3072**
set XMX_SUN_32BIT=**3072**
set XMS_JROCKIT_64BIT=**256**
set XMS_JROCKIT_32BIT=**256**
set XMX_JROCKIT_64BIT=**1024**
set XMX_JROCKIT_32BIT=**1024**

if "%JAVA_VENDOR%"=="Sun" (
    set WLS_MEM_ARGS_64BIT=**-Xms256m -Xmx512m**
    set WLS_MEM_ARGS_32BIT=**-Xms256m -Xmx512m**
) else (
    set WLS_MEM_ARGS_64BIT=**-Xms512m -Xmx512m**
    set WLS_MEM_ARGS_32BIT=**-Xms512m -Xmx512m**
)

तथा 

set MEM_PERM_SIZE_64BIT=-XX:PermSize=**256m**
set MEM_PERM_SIZE_32BIT=-XX:PermSize=**256m**

if "%JAVA_USE_64BIT%"=="true" (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT%
) else (
    set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT%
)

set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=**1024m**
set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=**1024m**
— शशि
स्रोत
4
ये सेटिंग्स केवल आपके स्थानीय आईडीई के लिए विशिष्ट हैं। यह उत्पाद पर्यावरण के लिए कोई काम नहीं करेगा।
— फेंग
-1

नेटबीन्स में, यह अधिकतम ढेर आकार को डिजाइन करने में मददगार हो सकता है। पर जाएं भागो => प्रोजेक्ट सेट विन्यास => अनुकूलित करें । इसके पॉप अप विंडो के रन में, VM विकल्प पर जाएं , भरें -Xms2048m -Xmx2048m। यह ढेर आकार की समस्या को हल कर सकता है।

— Xiaogang
स्रोत
-1

मेरे मैकबुक को रीबूट करते हुए मेरे लिए इस मुद्दे को तय किया।

— थॉमस
स्रोत
-1

मुझे नहीं पता कि यह अभी भी प्रासंगिक है या नहीं, लेकिन मेरे लिए जो काम किया है उसे साझा करना चाहता हूं।

नवीनतम उपलब्ध कोटलिन संस्करण को अपडेट करें। https://blog.jetbrains.com/kotlin/category/releases/

और हो गया।

— androidStud
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.