ত্রুটি 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
আমি কেবল সমস্যাটি পেয়েছি, যা গাদা সীমাবদ্ধতার খুব কাছে মেমরির ব্যবহারের দিকে নিয়ে যায়। জাভা-ইঞ্জিন (-এক্সএমএক্স) -কে আরও কিছু হিপ-মেমরি দেওয়া সহজ সমাধান হতে পারে তবে এটি কেবলমাত্র তখনই সহায়তা করে, যদি অ্যাপ্লিকেশনটির ঠিক তেমন মেমরির প্রয়োজন হয়, হিপ-সীমা নির্ধারিত হওয়ার আগে।
— মেনিমেথ
1
@Mnementh আমি একটি উত্তর দিয়েছিলেন এখানে চেক কিনা এটা সাহায্য করে stackoverflow.com/questions/11091516/...
— লুলু
16
@ সিমনকুয়াং নোট করুন যে একাধিক OutOfMemoryErrorপরিস্থিতি রয়েছে যার জন্য গাদা বৃদ্ধি কোনও বৈধ সমাধান নয়: নেটিভ থ্রেডের বাইরে চলে যাওয়া এবং পেরিম জেনের বাইরে চলে যাওয়া (যা গাদা থেকে পৃথক) দুটি উদাহরণ। সম্পর্কে অত্যধিক বিস্তৃত বিবৃতি দেওয়ার বিষয়ে সতর্ক থাকুন OutOfMemoryErrors; অপ্রত্যাশিতভাবে বিভিন্ন ধরণের জিনিস রয়েছে যা তাদের কারণ হতে পারে।
— টিম
3
আপনি কীভাবে বিষয়টি সমাধান করেছেন ??
— থর্স্টন নিহিউজ

উত্তর:

763

এই বার্তাটির অর্থ হ'ল কোনও কারণে আবর্জনা সংগ্রহকারী অতিরিক্ত পরিমাণে সময় নিচ্ছে (প্রক্রিয়াটির সমস্ত সিপিইউর 983% ডিফল্টরূপে) এবং প্রতিটি রানেই খুব অল্প স্মৃতি পুনরুদ্ধার করে (ডিফল্ট 2% গাদা)।

এর কার্যকর অর্থ হ'ল আপনার প্রোগ্রামটি যে কোনও অগ্রগতি বন্ধ করে দেয় এবং সর্বদা কেবল আবর্জনা সংগ্রহ চালাতে ব্যস্ত।

আপনার অ্যাপ্লিকেশনটিকে কোনও কাজ না করে সিপিইউ সময় ভেজানো থেকে বিরত রাখতে, জেভিএম এটিকে ছুঁড়ে দেয় Errorযাতে আপনার সমস্যাটি নির্ণয়ের সুযোগ থাকে।

বিরল ক্ষেত্রে যেখানে আমি এটি ঘটতে দেখেছি তা হ'ল কিছু কোড ইতিমধ্যে খুব স্মৃতি-সীমাবদ্ধ পরিবেশে প্রচুর অস্থায়ী অবজেক্ট এবং প্রচুর পরিমাণে দুর্বল-রেফারেন্সযুক্ত অবজেক্ট তৈরি করছিল।

জাভা জিসি টিউনিং গাইডটি দেখুন, যা বিভিন্ন জাভা সংস্করণের জন্য উপলভ্য এবং এই নির্দিষ্ট সমস্যা সম্পর্কিত বিভাগগুলি রয়েছে:

— জোছিম সাউর
সূত্র
9
আপনার উত্তরটির সংক্ষিপ্তসারটি সঠিকভাবে কি সঠিক হবে: "এটি 'জাভা হিপ স্পেসের বাইরে' ত্রুটির মতো। এক্সএমএক্সের সাথে আরও মেমরি দিন" " ?
— টিম কুপার
58
@ টিম: না, এটি সঠিক হবে না। এটিকে আরও মেমোরি দেওয়ার ফলে সমস্যাটি হ্রাস পেতে পারে, আপনার নিজের কোডটিও দেখে নেওয়া উচিত এবং এটি কেন এত পরিমাণ আবর্জনা তৈরি করে এবং আপনার কোডটি "মেমরির বাইরে" চিহ্নের ঠিক নীচে কেন স্কিম করে। এটি প্রায়শই ভাঙা কোডের একটি চিহ্ন।
— জোছিম সৌর
8
ধন্যবাদ, মনে হচ্ছে ওরাকল আসলে ডেটা মাইগ্রেশনে এতটা ভাল নয়, তারা লিঙ্কটি ভেঙে দিয়েছে।
— জোছিম সাউর
151
আপনি আমাকে "ধন্যবাদ, এটি দেখে মনে হচ্ছে ওরাকল আসলে খুব ভাল নয়"
— রব গ্রান্ট
3
@ গুউস: যদি একাধিক অ্যাপ্লিকেশন একই জেভিএমে চালিত হয়, তবে হ্যাঁ, তারা সহজেই একে অপরকে প্রভাবিত করতে পারে। কোনটি খারাপ ব্যবহার করছে তা বলা শক্ত হবে। অ্যাপ্লিকেশনগুলিকে আলাদা জেভিএমগুলিতে পৃথক করা সহজ সমাধান হতে পারে।
— জোছিম সাউর
215

ওরাকল এর "জাভা এসই 6 হটস্পট [টিএম] ভার্চুয়াল মেশিনের আবর্জনা সংগ্রহের টিউনিং" নিবন্ধ থেকে উদ্ধৃত করে :

অতিরিক্ত জিসি সময় এবং আউট অফ মেমরিরির

সমান্তরাল সংগ্রাহক আবর্জনা সংগ্রহে খুব বেশি সময় ব্যয় করা হলে একটি আউটআফমিউরিওর নিক্ষেপ করবে: মোট সময়ের 98% এরও বেশি যদি আবর্জনা সংগ্রহ করতে ব্যয় করা হয় এবং 2% এরও বেশি হিপটি পুনরুদ্ধার করা হয় তবে একটি আউটঅফমিউরিওর নিক্ষেপ করা হবে। এই বৈশিষ্ট্যটি খুব কম বা কোনও অগ্রগতির সময় অ্যাপ্লিকেশনগুলিকে সময়কালের জন্য চালানো থেকে বিরত রাখতে ডিজাইন করা হয়েছে কারণ গাদা খুব ছোট is প্রয়োজনে -XX:-UseGCOverheadLimitকমান্ড লাইনে অপশন যুক্ত করে এই বৈশিষ্ট্যটি অক্ষম করা যায়।

সম্পাদনা: দেখে মনে হচ্ছে কেউ আমার চেয়ে দ্রুত টাইপ করতে পারে :)

— ডেভ
সূত্র
87
"আপনি এটি বন্ধ করতে পারেন ..." তবে ওপি সম্ভবত এটি করা উচিত নয়।
— স্টিফেন সি
2
আপনি কি আমাকে "-XX" এবং "-Xmx" এর মধ্যে পার্থক্য বলতে পারবেন? আমি "-Xmx" বিকল্পটি ব্যবহার করে এটি বন্ধ করতে সক্ষম হয়েছি।
— সুশীল জাভাদি
19
এখানে একটি অতি পুরানো মন্তব্যের জবাব, কিন্তু ... @ বার্ট -XX:বেশ কয়েকটি কমান্ড লাইন বিকল্পের শুরুতে এক প্রকারের পতাকা এটি নির্দেশ করে যে এই বিকল্পটি অত্যন্ত ভিএম-নির্দিষ্ট এবং অস্থির (ভবিষ্যতের সংস্করণগুলিতে বিজ্ঞপ্তি ছাড়াই পরিবর্তন সাপেক্ষে)। যাই হোক না কেন, -XX:-UseGCOverheadLimitপতাকাটি ভিএমকে জিসি ওভারহেড সীমা পরীক্ষা করা (আসলে "এটি বন্ধ করে") অক্ষম করতে বলে, তবে আপনার -Xmxআদেশটি কেবল গাদা বাড়িয়ে দিয়েছে। পরবর্তী ক্ষেত্রে জিসি ওভারহেড চেকিং এখনও চলছিল , এটি কেবল শোনা যাচ্ছে যে আপনার ক্ষেত্রে জিসি থ্র্যাশিংয়ের সমস্যাগুলির সমাধান করা একটি বড় গাদা (এটি সর্বদা সহায়তা করবে না)।
— আন্দ্রেজেজ ডয়েল
1
আমার অ্যাপ্লিকেশনটিতে (টেল্যান্ডে একটি বৃহত এক্সেল ফাইলটি পড়া) এটি কার্যকর হয়নি এবং অন্যান্য ব্যবহারকারীদের ব্যাখ্যা থেকে আমি বুঝতে পারি why এটি কেবল ত্রুটি অক্ষম করে তবে সমস্যাটি অব্যাহত থাকে এবং আপনার অ্যাপ্লিকেশনটি কেবলমাত্র জিসি পরিচালনার বেশিরভাগ সময় ব্যয় করবে। আমাদের সার্ভারে প্রচুর পরিমাণে র্যাম ছিল তাই আমি ভিটালির পরামর্শগুলি ব্যবহার করে স্তূপের আকার বাড়াতে।
— রবজেড
আপনার অ্যাপ্লিকেশনটি যদি ডেটা নিবিড় হয় তবে অবশেষে আপনি এই ত্রুটিটি পেয়ে যাবেন, মেমরিটি সাফ করা এবং ডেটা ফাঁসকে ছাড়িয়ে তোলা সবচেয়ে ভাল উপায় - তবে কিছুটা সময় প্রয়োজন।
— পাইভিস
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-বি07 ব্যবহার করা।

java -Xloggc:gc.log GarbageCollector

তারপরে দেখুন gc.log

  • বিএডি পদ্ধতি ব্যবহার করে ৪৪৪ বার ট্রিগার করা
  • WORSE পদ্ধতি ব্যবহার করে 666 বার ট্রিগার করা
  • উন্নত পদ্ধতিটি ব্যবহার করে 354 বার ট্রিগার করা হয়েছে

এখন মঞ্জুর করা হয়েছে, এটি সেরা পরীক্ষা বা সেরা নকশা নয় তবে এমন পরিস্থিতির মুখোমুখি যখন আপনি যেমন লুপ প্রয়োগ ছাড়া কোন বিকল্প নেই বা বিদ্যমান আচরণের সাথে খারাপ আচরণ করে যখন নতুন তৈরির পরিবর্তে অবজেক্টগুলিকে পুনরায় ব্যবহার করা বাছাই করা হ্রাস করতে পারে আবর্জনা সংগ্রহকারী কতবার পথে যায় ...

— মাইক
সূত্র
12
দয়া করে স্পষ্ট করে বলুন: আপনি যখন "ট্রিগার্ড এন টাইম" বলছেন, তার মানে কি নিয়মিত জিসি এন বার হয়েছে, বা "জিসি ওভারহেডের সীমা অতিক্রম করেছে" ওপি দ্বারা রিপোর্ট করা ত্রুটি n বার হয়েছে?
— জন স্নাইডার
আমি এখনই জাভা 1.8.0_91 ব্যবহার করে পরীক্ষা করেছি এবং কখনই ত্রুটি / ব্যতিক্রম পাইনি এবং "ট্রিগার্ড এন টাইম" gc.logফাইলটির লাইন সংখ্যা গণনা করা থেকে হয়েছিল । আমার পরীক্ষাগুলি সামগ্রিক তুলনায় অনেক কম বার দেখায়, তবে বেটারের জন্য খুব কম "ট্রিগার" সময় দেখায় এবং এখন, বিএডিএস এখন ওয়ার্ল্ডের চেয়ে "খারাপ"। আমার গণনা: বিএডি: ২,, যুদ্ধ: ২২, উত্তম 21.
— মার্ক স্টিয়ার্ট
আমি শুধু একটি "WORST_YET" পরিমার্জন যেখানে আমি সংজ্ঞায়িত যোগ List<Double> listমধ্যে বাইরের লুপ পরিবর্তে সামনে বাইরের লুপ, এবং 39 আবর্জনা সংগ্রহের আলোড়ন সৃষ্টি।
— মার্ক স্টুয়ার্ট
36

জাভা অনুসারে ত্রুটির কারণ [8] প্ল্যাটফর্ম, স্ট্যান্ডার্ড সংস্করণ ট্রাবলশুটিং গাইড : (জোর দেওয়া এবং লাইন ব্রেকগুলি যুক্ত করা হয়েছে)

[...] "জিসি ওভারহেডের সীমা অতিক্রম করে" ইঙ্গিত দেয় যে আবর্জনা সংগ্রহকারী সর্বদা চলছে এবং জাভা প্রোগ্রামটি খুব ধীর গতিতে চলছে।

কোনও আবর্জনা সংগ্রহের পরে, যদি জাভা প্রক্রিয়াটি তার প্রায় 98% সময়ের চেয়ে বেশি সময় ব্যয় করে আবর্জনা সংগ্রহ করতে এবং যদি এটি 2% এরও কম recoverগল সেরে নিয়ে চলেছে এবং এ পর্যন্ত সর্বশেষ 5 টি (সংকলনের সময় ধ্রুবক) আবর্জনা করে চলেছে সংগ্রহ, তারপরে একটি java.lang.OutOfMemoryErrorনিক্ষেপ করা হয় [...]

  1. গাদা আকার বাড়ান যদি বর্তমান গাদা পর্যাপ্ত পরিমাণ না থাকে।
  2. আপনি যদি এখনও বাড়ছে গাদা মেমরি পরে এই ত্রুটি পান, তাহলে ব্যবহার মেমরির সরঞ্জাম প্রোফাইলিং মত মাদুর (মেমরি বিশ্লেষক টুল), ভিসুয়াল VM- র ইত্যাদি ব্যবহার করুন এবং মেমরি ফাঁস ঠিক করুন।
  3. জেডিকে সংস্করণকে সর্বশেষতম সংস্করণ (1.8.x) বা কমপক্ষে 1.7.x এ আপগ্রেড করুন এবং জি 1 জিসি অ্যালগরিদম ব্যবহার করুন। । জি 1 জিসির জন্য থ্রুপুট লক্ষ্যটি 90 শতাংশ প্রয়োগের সময় এবং 10 শতাংশ আবর্জনা সংগ্রহের সময়

  4. - দিয়ে হিপ মেমরি সেট করা ছাড়াও Xms1g -Xmx2gচেষ্টা করুন

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

জি 1 জিসি সম্পর্কিত আরও কিছু সম্পর্কিত প্রশ্ন দেখুন

— রবীন্দ্র বাবু
সূত্র
29

এই বিকল্পটি সেট করে কিছুটা গাদা আকার বাড়ান

রান Config কনফিগারেশন চালান gu আর্গুমেন্টগুলি → ভিএম আর্গুমেন্ট

-Xms1024M -Xmx2048M

এক্সএমএস - সর্বনিম্ন সীমাতে

এক্সএমএক্স - সীমাবদ্ধতার জন্য

— chopss
সূত্র
2
অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলির argumentsট্যাব নেই ... এটি অর্জনের জন্য আমাদের কী করা উচিত?
— জ্বলুন তামা
3
কিসের জন্য উত্তর? এটি কোনও গ্রহণের প্রশ্ন ছিল না।
— মাইকেল পিফেল
3
কোনও "ন্যূনতম সীমা" নেই। -Xms প্রাথমিক আকার।
— দিয়েগো কুইরোজ
1
সর্বোচ্চ সীমা কতটুকু সেট করা যেতে পারে ??
— জেপার্ক
14

আমার জন্য, নিম্নলিখিত পদক্ষেপগুলি কাজ করেছে:

  1. eclipse.iniফাইলটি খুলুন

  2. পরিবর্তন

    -Xms40m
-Xmx512m

    প্রতি

    -Xms512m
-Xmx1024m

  3. পুনরায় সূচনা Eclipse

এখানে দেখো

— সুনীল কুমার সাহু
সূত্র
এই সমস্যাটি সমাধানের সবচেয়ে সহজ উপায়। ধন্যবাদ :)
— হামজা
1
জেদেহে eclipse.ini ফাইল?
— অভিনববা বসু
কনফিগারেশনটি এতে পরিবর্তন করা হলেও সমস্যাগুলি সমাধান হয়নি।
— zionpi
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"
    }
}
— HSH
সূত্র
হ্যাঁ, গ্রেডল ব্যবহার করার সময় :)
— অ্যালেক্স
4
আপনি কীভাবে ভাবতে পারেন যে এটি সাধারণভাবে তাঁর প্রশ্নের সমাধান ? আপনি 4g আপনার গাদা আকার যা Android এর জন্য একটি gradle কনফিগারেশনে সম্পূর্ণভাবে নির্বিচারে সেট facepalm ।
— জুলিয়ান এল।
7

আপনার বিল্ড.gradle (মডিউল: অ্যাপ) ফাইলটিতে javaMaxHeapsize বাড়ান

dexOptions {
    javaMaxHeapSize "1g"
}

এ (গ্রেডে এই লাইনটি যুক্ত করুন)

 dexOptions {
        javaMaxHeapSize "4g"
    }
— সাই গোপী এন
সূত্র
3

জাভা হ্যাপ সাইজের বর্ণনা (এক্সএমএস, এক্সএমএক্স, এক্সএমএন)

-Xms size in bytes

Example : java -Xms32m

জাভা হ্যাপের প্রাথমিক আকার সেট করে। ডিফল্ট আকার 2097152 (2MB)। মানগুলি অবশ্যই 1024 বাইট (1KB) এর একাধিক এবং বৃহত্তর হতে হবে। (সার্ভারের পতাকাটি ডিফল্ট আকারটি 32M-তে বাড়িয়ে দেয়))

-Xmn size in bytes

Example : java -Xmx2m

ইডেন প্রজন্মের জন্য প্রাথমিক জাভা হিপ আকার সেট করে। ডিফল্ট মান 640K। (সার্ভারের পতাকাটি ডিফল্ট আকারটিকে 2M-তে বাড়িয়ে তোলে))

-Xmx size in bytes

Example : java -Xmx2048m

জাভা হিপ বাড়তে পারে এমন সর্বোচ্চ আকার সেট করে। ডিফল্ট আকার 64M। (-সার্ভার পতাকাটি ডিফল্ট আকারটিকে 128 এম-তে বাড়িয়ে দেয়)) সর্বাধিক হ্যাপের সীমাটি প্রায় 2 জিবি (2048 এমবি)।

জাভা মেমরি আর্গুমেন্ট (xms, xmx, xmn) ফর্ম্যাটিং

জাভা হ্যাপের আকার নির্ধারণ করার সময়, আপনার এমবি জন্য "এম" বা "এম" বর্ণগুলির একটি বা জিবি জন্য "জি" বা "জি" অক্ষর ব্যবহার করে আপনার স্মৃতি যুক্তিটি নির্দিষ্ট করতে হবে। আপনি "এমবি" বা "জিবি" নির্দিষ্ট করে দিলে আপনার সেটিংটি কাজ করবে না। বৈধ আর্গুমেন্টগুলি এর মতো দেখায়:

-Xms64m বা -Xms64M -Xmx1g বা -Xmx1G 2GB নির্দিষ্ট করতে 2048MB ব্যবহার করতে পারে এছাড়াও, আপনার আর্গুমেন্টগুলি নির্দিষ্ট করার সময় আপনি কেবল পুরো সংখ্যা ব্যবহার করেছেন তা নিশ্চিত করুন। -Xmx512m ব্যবহার করা একটি বৈধ বিকল্প, তবে -Xmx0.5g একটি ত্রুটি ঘটায়।

এই রেফারেন্স কারও পক্ষে সহায়ক হতে পারে।

— রূপকথার পক্ষি বিশেষ
সূত্র
2

আপনি এটিকে আপনার gradle.propertiesফাইলে যুক্ত করে মেমরি বরাদ্দ এবং হিপ আকার বাড়িয়ে তুলতে পারেন :

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

এটি 2048 এম এবং 32 জি হতে হবে না, এটি আপনার পছন্দ মতো বড় করুন।

— জন দো
সূত্র
2

মীমাংসিত:
শুধু যোগ
org.gradle.jvmargs=-Xmx1024m
মধ্যে
gradle.properties
এবং এটি যদি বিদ্যমান নয়, এটা তৈরি করুন।

— reza_khalafi
সূত্র
0

আমি অ্যান্ড্রয়েড স্টুডিওতে কাজ করছি এবং মুক্তির জন্য একটি স্বাক্ষরিত APK তৈরি করার চেষ্টা করার সময় এই ত্রুটির মুখোমুখি হয়েছি। আমি কোনও সমস্যা ছাড়াই একটি ডিবাগ এপিকে তৈরি করতে এবং পরীক্ষা করতে সক্ষম হয়েছি, তবে আমি যখনই একটি রিলিজ APK বানাতে চাইছিলাম, বিল্ড প্রক্রিয়াটি কয়েক মিনিটের জন্য চলবে এবং শেষ পর্যন্ত "ত্রুটি জাভা.লং.আউটআউফমিউরিওর দিয়ে শেষ হবে: জিসি ওভারহেড সীমা অতিক্রম করেছে "। আমি ভিএম এবং অ্যান্ড্রয়েড ডেক্স সংকলক উভয়ের জন্য হিপ আকারগুলি বাড়িয়েছি, তবে সমস্যাটি থেকেই যায়। অবশেষে, অনেক ঘন্টা এবং কফি মগের পরে দেখা গেল যে সমস্যাটি আমার অ্যাপ্লিকেশন-স্তরের 'বিল্ড.gradle' ফাইলে রয়েছে - রিলিজ বিল্ড টাইপের জন্য আমার 'মিনিফাইনেবল' প্যারামিটার ছিল, ফলস্বরূপ প্রগার্ড স্টাফগুলি চলছে I কোডে যা কোড-সঙ্কুচিত 'প্রক্রিয়াটির মধ্য দিয়ে যায় নি (দেখুন https://developer.android দেখুন।)। আমি 'মিনিফাইনেবল' প্যারামিটারটি 'সত্য' তে পরিবর্তন করেছি এবং মুক্তির বিল্ডটি স্বপ্নের মতো কার্যকর করা হয়েছে :)

সংক্ষেপে, আমাকে আমার অ্যাপ্লিকেশন স্তরের '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

ইন্টেলিজ আইডিইএর স্তূপের আকার বাড়াতে নিম্নলিখিত নির্দেশাবলী অনুসরণ করুন। এটা আমার জন্য কাজ করেছে।

উইন্ডোজ ব্যবহারকারীদের জন্য,

যেখানে আইডিই ইনস্টল করা আছে সেখানে যান এবং নিম্নলিখিতগুলির জন্য অনুসন্ধান করুন।

idea64.exe.vmoptions

ফাইলটি সম্পাদনা করুন এবং নিম্নলিখিত যুক্ত করুন।

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

হ্যাঁ, ওটাই !!

— ডুলিথ দে কস্তা
সূত্র
0

আপনি এই চিত্রটি উল্লেখ করে সার্ভার সেটিং-এ পরিবর্তন করার চেষ্টা করতে পারেন এবং প্রসেসিং প্রক্রিয়া পরিবর্তনের জন্য মেমরির আকার বাড়াতে পারেন হলুদে হাইলাইট

আপনি cmd-> খোলার মাধ্যমে জাভা হিপগুলিতেও পরিবর্তন আনতে পারেন set _java_opts -Xmx2g
নিজের প্রোগ্রামের জটিলতার উপর নির্ভর করে 2g (2 গিগাবাইট)

কম ধ্রুবক ভেরিয়েবল এবং টেম্প ভেরিয়েবলগুলি ব্যবহার করার চেষ্টা করুন

এখানে চিত্র বর্ণনা লিখুন

— রাহুল জৈন
সূত্র
-1

আপনাকে জেডোলেফায়ারে মেমরির আকার বাড়াতে হবে সেটডোমেনইএনভি সিএমডি যান ।

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

নেটবিন্সে, এটি সর্বোচ্চ গাদা আকারের নকশা তৈরি করতে সহায়ক হতে পারে। যান রান => সেট প্রকল্প কনফিগারেশন => কাস্টমাইজ । ইন চালান তার popped আপ উইন্ডোর, এখানে যান VM- র অপশন মধ্যে ভরাট -Xms2048m -Xmx2048m। এটি গাদা আকারের সমস্যা সমাধান করতে পারে।

— Xiaogang
সূত্র
-1

আমার ম্যাকবুকটি পুনরায় বুট করা আমার জন্য এই সমস্যাটি স্থির করেছে।

— টমাস
সূত্র
-1

আমি জানি না এটি এখনও প্রাসঙ্গিক কিনা বা না, তবে আমার জন্য কী কাজ করেছে তা কেবল ভাগ করে নিতে চাই।

সর্বশেষ উপলব্ধ থেকে কোটলিন সংস্করণ আপডেট করুন। https://blog.jetbrains.com/kotlin/category/releases/

এবং এটি সম্পন্ন হয়েছে।

— androidStud
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.