it-swarm-tr.com

"Java.lang.OutOfMemoryError: PermGen space" hatası ile başa çıkmak

Son zamanlarda web uygulamamda bu hatayı karşıladım:

Java.lang.OutOfMemoryError: PermGen alanı

Tomcat 6 ve JDK 1.6'da çalışan tipik bir Hibernate/JPA + IceFaces/JSF uygulamasıdır. Anlaşılan bu, bir uygulamanın birkaç kez yeniden dağıtılmasından sonra ortaya çıkabilir.

Buna sebep olan nedir ve önlemek için ne yapılabilir? Sorunu nasıl düzeltebilirim?

1206
Chris

Çözüm, Tomcat başlatıldığında bu bayrakları JVM komut satırına eklemek oldu:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Bunu, Tomcat servisini kapatıp ardından Tomcat/bin dizinine gidip Tomcat6w.exe dosyasını çalıştırarak yapabilirsiniz. "Java" sekmesi altında, "Java Seçenekleri" kutusuna değişkenleri ekleyin. "Tamam" ı tıklayın ve ardından servisi yeniden başlatın.

Bir hata alırsanız belirtilen servis kurulu bir servis olarak mevcut değil çalıştırmalısınız:

Tomcat6w //ES//servicename

neredeservicenameservices.msc'de görüntülenen sunucunun adıdır

Kaynak: orx'un Eric'in Çevik Cevapları ile ilgili yorumu.

560
Chris

-XX:MaxPermSize=128M yerine-XX:MaxPermGen=128Mkomutunu denemelisiniz.

Bu bellek havuzunun tam olarak kullanıldığını söyleyemem, ancak JVM'ye yüklenen sınıfların sayısıyla ilgili olmalı. (Bu nedenle Tomcat için sınıf boşaltma işlemini etkinleştirmek sorunu çözebilir.) Uygulamalarınız çalışma sırasında sınıflar oluşturur ve derlerse, varsayılandan daha büyük bir bellek havuzuna ihtiyaç duyulması daha olasıdır.

250
toesterdahl

İnsanların yaptığı yaygın hatalar, yığın alanı ile permgen alanın aynı olduğunu ve bunun gerçek olmadığını düşünüyor. Yığında kalan boş alan olabilir, ancak hala permgen içinde belleği yetersiz olabilir.

PermGen'deki OutofMemory'nin ortak nedenleri ClassLoader'dır. Bir sınıf JVM'ye ne zaman yüklenirse, tüm meta verileri Classloader ile birlikte PermGen alanında tutulur ve onları yükleyen Classloader çöp toplamaya hazır olduğunda toplanırlar. Durumunda Classloader tarafından yüklenen tüm sınıflardan daha fazla bellek sızıntısı olması durumunda, bellekte kalır ve birkaç kez tekrarladığınızda permGen uygulamasına neden olur. Klasik örnek Java.lang.OutOfMemoryError: Tomcat'taki PermGen Space .

Şimdi bunu çözmenin iki yolu var:
1. Bellek sızıntısının nedenini veya herhangi bir bellek sızıntısı olup olmadığını bulun.
2. JVM param -XX:MaxPermSize ve -XX:PermSize komutlarını kullanarak PermGen Space boyutunu artırın.

Daha fazla bilgi için ayrıca 2 Java.lang.OutOfMemoryError in Java çözümünü de kontrol edebilirsiniz.

67
Peter

Sun JVM için -XX:MaxPermSize=128m komut satırı parametresini kullanın (açıkçası, istediğiniz boyut için 128 yerine).

40
user17163

-XX:MaxPermSize=256m'u deneyin ve devam ederse -XX:MaxPermSize=512m'u deneyin.

36
bassist

I -XX: MaxPermSize = 128m (hangisinin daha iyi çalıştığını deneyebilirsiniz), Eclipse ide kullandığımdan VM Bağımsız Değişkenler öğesine eklenir. JVM'nin çoğunda, varsayılan PermSize , projede çok fazla sınıf veya çok fazla Dizge varsa, bellek tükenen 64MB civarındadır.

Eclipse için ayrıca answer .

1. ADIM: Tomcat sunucusunda Sunucular Sekmesinde çift tıklayın

enter image description here

2. ADIM: Conf açılışını açın ve varolan VM düzenlemeleri sonuna -XX: MaxPermSize = 128m ekleyin.

enter image description here

26
prayagupd

Ben de karmaşık bir web uygulamasını da kurarken ve dağıtırken bu soruna karşı kafamı çarpıyordum ve bir açıklama ve çözüm ekleyeceğimi düşündüm.

Apache Tomcat'ta bir uygulama dağıtırken, bu uygulama için yeni bir ClassLoader oluşturuldu. ClassLoader, daha sonra tüm uygulamaların sınıflarını yüklemek için kullanılır ve geridönüşlerde her şeyin güzel bir şekilde giderilmesi gerekir. Ancak, gerçekte bu kadar basit değil.

Web uygulamasının ömrü boyunca oluşturulan sınıflardan biri veya daha fazlası, satır boyunca bir yerde ClassLoader'a başvuran statik bir referans tutar. Referans başlangıçta statik olduğundan, hiçbir atık toplama işlemi bu referansı temizleyemez - ClassLoader ve yüklediği tüm sınıflar burada kalır.

Birkaç yeniden dağıtımdan sonra, OutOfMemoryError ile karşılaştık.

Şimdi bu oldukça ciddi bir problem haline geldi. Her yeniden dağıtımdan sonra Tomcat’in yeniden başlatıldığından emin olabilirim, ancak bu genellikle yeniden uygulanamayan bir uygulama yerine tüm sunucuyu kapsıyor.

Bunun yerine Apache Tomcat 6.0'da çalışan koda bir çözüm koydum. Başka hiçbir uygulama sunucusunda test etmedim ve şunu vurgulamalıyım ki bu, başka herhangi bir uygulama sunucusunda değişiklik yapmadan çalışmama olasılığı yüksektir.

Ayrıca, şahsen bu koddan nefret ettiğimi ve mevcut kodun uygun kapatma ve temizleme yöntemlerini kullanacak şekilde değiştirilebiliyorsa, hiç kimsenin bunu "hızlı bir düzeltme" olarak kullanmaması gerektiğini söylemek isterim. Kullanmanız gereken, kodunuzun bağımlı olduğu harici bir kütüphane varsa (Benim durumumda, bir RADIUS istemcisi) kendi statik referanslarını temizlemenin bir yolunu sağlamıyor.

Neyse, kodla devam et. Bu, uygulamanın dağıtılmadığı noktada çağrılmalıdır - bir sunucu uygulamasının yok etme yöntemi veya (daha iyi bir yaklaşım) bir ServletContextListener'ın bağlamıAyrılmış yöntemi.

//Get a list of all classes loaded by the current webapp classloader
WebappClassLoader classLoader = (WebappClassLoader) getClass().getClassLoader();
Field classLoaderClassesField = null;
Class clazz = WebappClassLoader.class;
while (classLoaderClassesField == null && clazz != null) {
    try {
        classLoaderClassesField = clazz.getDeclaredField("classes");
    } catch (Exception exception) {
        //do nothing
    }
    clazz = clazz.getSuperclass();
}
classLoaderClassesField.setAccessible(true);

List classes = new ArrayList((Vector)classLoaderClassesField.get(classLoader));

for (Object o : classes) {
    Class c = (Class)o;
    //Make sure you identify only the packages that are holding references to the classloader.
    //Allowing this code to clear all static references will result in all sorts
    //of horrible things (like Java segfaulting).
    if (c.getName().startsWith("com.whatever")) {
        //Kill any static references within all these classes.
        for (Field f : c.getDeclaredFields()) {
            if (Modifier.isStatic(f.getModifiers())
                    && !Modifier.isFinal(f.getModifiers())
                    && !f.getType().isPrimitive()) {
                try {
                    f.setAccessible(true);
                    f.set(null, null);
                } catch (Exception exception) {
                    //Log the exception
                }
            }
        }
    }
}

classes.clear();
22
Edward Torbett

1) PermGen Bellek Boyutunun Artırılması

Yapılabilecek ilk şey, kalıcı nesil yığın boşluğunun boyutunu büyütmektir. Bu, normal –Xms (ilk öbek boyutu ayarla) ve –Xmx (maksimum öbek boyutu ayarla) JVM argümanları ile yapılamaz, çünkü belirtildiği gibi, kalıcı nesil öbek alanı tamamen Java Öbek alanından tamamen ayrılır ve bu argümanlar ayarlanır. Bu düzenli Java yığın alanı için boşluk. Ancak, kalıcı nesil yığınının boyutunu büyütmek için kullanılabilecek benzer argümanlar vardır (en azından Sun/OpenJDK jvms ile):

 -XX:MaxPermSize=128m

Varsayılan değer 64m'dir.

2) Süpürmeyi Etkinleştir

İyiliğe dikkat etmenin bir başka yolu, sınıfların boşaltılmasını sağlamaktır, böylece PermGen asla bitmez:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

Bunun gibi şeyler geçmişte benim için sihir yaptı. Yine de bir şey var ki, bunları kullanmakta önemli bir performans var, çünkü permgen taramaları, yaptığınız her istek için veya bu hatlar boyunca bir şey için ekstra 2 talep gibi olacak. Kullanımınızı değişimlerle dengelemeniz gerekir.

Bu hatanın ayrıntılarını bulabilirsiniz.

http://faisalbhagat.blogspot.com/2014/09/Java-outofmemoryerror-permgen.html

15
faisalbhagat

Alternatif olarak, Sun'ın jvm'sinden farklı olarak permgenleri kullanan JRockit'e geçebilirsiniz. Genel olarak da daha iyi performansa sahiptir.

http://www.Oracle.com/technetwork/middleware/jrockit/overview/index.html

15
Jeremy

Java.lang.OutOfMemoryError: PermGen alan mesajı, Kalıcı Nesil’in bellekteki alanının tükendiğini gösterir.

Herhangi bir Java uygulamasının sınırlı miktarda bellek kullanmasına izin verilir. Uygulama başlangıcında, uygulamanızın kullanabileceği tam bellek miktarı belirtilir.

Java belleği, aşağıdaki resimde görülebilecek farklı bölgelere ayrılmıştır:

 enter image description here

Metaspace: Yeni bir bellek alanı doğdu

JDK 8 HotSpot JVM şimdi sınıf meta verilerinin gösterimi için yerel bellek kullanıyor ve Metaspace; Oracle JRockit ve IBM JVM'lere benzer.

İyi haber şu ki, artık Java.lang.OutOfMemoryError: PermGen alan sorunu yok demektir ve Java_8_Download veya daha üstünü kullanarak artık bu bellek alanını ayarlamanıza ve izlemenize gerek yoktur.

14
Santosh Jadi

Bugünlerde en basit cevap Java 8 kullanmak.

Artık sadece PermGen alanı için hafıza ayırmıyor, PermGen hafızasının normal hafıza havuzuyla eşleşmesini sağlıyor.

Java 8'in hiçbir şey yapmadıklarından şikayet etmesini istemiyorsanız, standart olmayan -XXPermGen...=... JVM başlangıç ​​parametrelerinin tümünü kaldırmanız gerekeceğini unutmayın.

13
Edwin Buck

Burada bahsettiğimiz sorun vardı, benim senaryom Eclipse-helios + Tomcat + jsf ve yaptığınız şey Tomcat'a basit bir uygulama dağıtmak. Burada da aynı sorunu gösteriyordum, aşağıdaki gibi çözdüm.

Eclipse, server sekmesine gidin, benim durumum Tomcat 7.0 olan kayıtlı sunucuya çift tıklayın, bu benim dosya sunucumu açar Genel kayıt bilgileri. "Genel Bilgi" bölümünde, "Açılış yapılandırmasını aç" bağlantısını tıklayın, bu, VM argümanlarında Argümanlar sekmesinde sunucu seçeneklerinin yürütülmesini açar. bu iki girişi sonlandır

-XX: MaxPermSize = 512m
-XX: PermSize = 512m

ve hazır.

13
Hugo Mendoza
  1. Tomcat'ın bin dizininden Tomcat7w'yi açın veya başlat menüsüne Monitor Tomcat'i yazın (sekmeli bir pencere çeşitli servis bilgileriyle açılır).
  2. Java Seçenekleri metin alanında bu satırı ekleyin:

    -XX:MaxPermSize=128m
    
  3. İlk Bellek Havuzunu 1024'e (isteğe bağlı) ayarlayın.
  4. Maksimum Bellek Havuzunu 1024'e (isteğe bağlı) ayarlayın.
  5. Tamam'ı tıklayın.
  6. Tomcat servisini yeniden başlatın.
8
Lucky

Perm gen alanı hatası, jvm yerine kodun çalıştırılması için yeterli alan kullanılması nedeniyle oluşur. UNIX işletim sistemlerinde bu problem için en iyi çözüm, bash dosyasındaki bazı konfigürasyonları değiştirmektir. Aşağıdaki adımlar sorunu çözer.

Terminalde gedit .bashrc komutunu çalıştırın.

Aşağıdaki değerle Java_OTPS değişkenini oluşturun:

export Java_OPTS="-XX:PermSize=256m -XX:MaxPermSize=512m"

Bash dosyasını kaydedin. Terminalde exec bash komutunu çalıştırın. Sunucuyu yeniden başlatın.

Umarım bu yaklaşım probleminizde işe yarayacaktır. Java sürümünü 8'den küçük kullanıyorsanız, bu sorun bazen oluşur. Ancak Java 8 kullanıyorsanız, sorun hiçbir zaman gerçekleşmez.

6
Darshan

Kalıcı Nesil boyutunun arttırılması veya ince ayarlı GC parametreleri, gerçek bir hafıza sızıntınız varsa yardımcı olmayacaktır. Uygulamanız veya kullandığı bazı 3. taraf kütüphaneleri, sınıf yükleyicilerini kaçaklarsa, gerçek ve kalıcı çözüm bu sızıntıyı bulmak ve düzeltmektir. Size yardımcı olabilecek çok sayıda araç var, bunlardan bir tanesi Plumbr .

5
Nikem

Ayrıca web uygulamanızda log4j kullanıyorsanız, bu paragrafı log4j document 'de kontrol edin.

Görünüşe göre PropertyConfigurator.configureAndWatch("log4j.properties") kullanıyorsanız, web uygulamanızı dağıtırken bellek sızıntısına neden olursunuz.

5

jrockit bunu benim için de çözdü; Ancak, sunucu uygulamasının yeniden başlatılma zamanlarının çok daha kötü olduğunu fark ettim, bu yüzden üretimde daha iyi olmasına rağmen, gelişimde bir tür sürüklenme oldu.

4
Tim Howland

Hibernate + Eclipse RCP'nin bir kombinasyonu var, -XX:MaxPermSize=512m ve -XX:PermSize=512m kullanmaya çalıştım ve bu benim için çalışıyor gibi görünüyor.

4
Pankaj Shinde

Birkaç cevap denedim ve nihayet işi yapan tek şey pom'daki derleyici eklentisi için bu konfigürasyondu:

<plugin>
    <groupId>org.Apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <fork>true</fork>
        <meminitial>128m</meminitial>
        <maxmem>512m</maxmem>
        <source>1.6</source>
        <target>1.6</target>
        <!-- prevent PermGen space out of memory exception -->
        <!-- <argLine>-Xmx512m -XX:MaxPermSize=512m</argLine> -->
    </configuration>
</plugin>

umarım bu yardımcı olur.

4
kiwilisk

-XX:PermSize=64m -XX:MaxPermSize=128m değerini ayarlayın. Daha sonra ayrıca MaxPermSize değerini arttırmayı deneyebilirsiniz. Umarım işe yarar. Aynı benim için çalışıyor. Yalnızca MaxPermSize ayarı benim için işe yaramadı.

4
sandeep

Tomcat'a daha fazla bellek atamak uygun bir çözüm DEĞİLDİR.

Doğru çözüm, içerik yok edildikten ve yeniden yaratıldıktan sonra (sıcak dağıtım) temizleme yapmaktır. Çözüm, bellek sızıntılarını durdurmaktır.

Tomcat/Webapp Sunucunuz size sürücülerin kaydını silemediğinizi söylüyorsa (JDBC), sonra bunların kaydını kaldırın. Bu bellek sızıntılarını durduracak.

Bir ServletContextListener oluşturabilir ve web.xml'inizde yapılandırabilirsiniz. İşte bir ServletContextListener örneği:

import Java.sql.Driver;
import Java.sql.DriverManager;
import Java.sql.SQLException;
import Java.util.Enumeration;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

import org.Apache.log4j.Logger;

import com.mysql.jdbc.AbandonedConnectionCleanupThread;

/**
 * 
 * @author alejandro.tkachuk / calculistik.com
 *
 */
public class AppContextListener implements ServletContextListener {

    private static final Logger logger = Logger.getLogger(AppContextListener.class);

    @Override
    public void contextInitialized(ServletContextEvent arg0) {
        logger.info("AppContextListener started");
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0) {
        logger.info("AppContextListener destroyed");

        // manually unregister the JDBC drivers
        Enumeration<Driver> drivers = DriverManager.getDrivers();
        while (drivers.hasMoreElements()) {
            Driver driver = drivers.nextElement();
            try {
                DriverManager.deregisterDriver(driver);
                logger.info(String.format("Unregistering jdbc driver: %s", driver));
            } catch (SQLException e) {
                logger.info(String.format("Error unregistering driver %s", driver), e);
            }

        }

        // manually shutdown clean up threads
        try {
            AbandonedConnectionCleanupThread.shutdown();
            logger.info("Shutting down AbandonedConnectionCleanupThread");
        } catch (InterruptedException e) {
            logger.warn("SEVERE problem shutting down AbandonedConnectionCleanupThread: ", e);
            e.printStackTrace();
        }        
    }
}

Ve burada web.xml'nizde konfigüre edersiniz:

<listener>
    <listener-class>
        com.calculistik.mediweb.context.AppContextListener 
    </listener-class>
</listener>  

Tomcat'in en son revizyonunun (6.0.28 veya 6.0.29) servetleri yeniden dağıtma görevini yerine getirdiğini çok daha iyi olduğunu söylüyorlar.

3
Tony Ennis

Bu durumda ilk adım, GC'nin sınıfları PermGen'den boşaltmasına izin verilip verilmediğini kontrol etmektir. Standart JVM bu konuda oldukça tutucudur - sınıflar sonsuza dek yaşamak için doğarlar. Bu yüzden bir kere yüklendiğinde, sınıflar artık kod kullanmıyor olsa bile bellekte kalır. Uygulama dinamik olarak birçok sınıf oluşturduğunda ve oluşturulan sınıflara daha uzun süre ihtiyaç duyulmadığında sorun olabilir. Böyle bir durumda, JVM'nin sınıf tanımlarını kaldırmasına izin vermek yararlı olabilir. Bu, başlangıç ​​komut dosyalarınıza yalnızca bir yapılandırma parametresi ekleyerek sağlanabilir:

-XX:+CMSClassUnloadingEnabled

Varsayılan olarak bu yanlış olarak ayarlanmıştır ve bu yüzden bunu etkinleştirmek için Java seçeneklerinde aşağıdaki seçeneği açıkça ayarlamanız gerekir. CMSClassUnloadingEnabled özelliğini etkinleştirirseniz, GC, PermGen'i de süpürür ve artık kullanılmayan sınıfları kaldırır. Bu seçeneğin yalnızca UseConcMarkSweepGC'nin aşağıdaki seçeneği kullanarak da etkinleştirilmesi durumunda çalışacağını unutmayın. Bu nedenle, ParallelGC'yi veya God God for Sid, Seri GC'yi çalıştırırken, GC'yi CMS'ye ayarlayarak emin olun:

-XX:+UseConcMarkSweepGC
3
sendon1982

Ben de aynı problemle karşılaştım, fakat ne yazık ki önerilen çözümlerin hiçbiri benim için işe yaramadı. Sorun dağıtım sırasında olmadı ve hiçbirinde sıcak dağıtım yapmıyordum.

Benim durumumda sorun web uygulamamın yürütülmesi sırasında her zaman aynı noktada meydana geldi, veritabanına bağlanırken (hazırda bekletme moduyla).

Bu bağlantı (daha önce de belirtildiği gibi) sorunu çözmek için yeterli bilgi sağlamıştır. Jdbc- (mysql) -driver'ı WEB-INF'den ve jre/lib/ext/klasörüne taşımak sorunu çözmüş gibi görünüyor. Yeni bir JRE'ye yükseltme yapmak sürücüyü yeniden yüklemenizi gerektireceğinden bu ideal çözüm değildir. Benzer sorunlara yol açabilecek bir başka aday da log4j'dir, dolayısıyla onu da taşımak isteyebilirsiniz.

3
Maze

Hafızanın yapılandırması, uygulamanızın doğasına bağlıdır.

Ne yapıyorsun?

Kullanılan işlem miktarı nedir?

Ne kadar veri yüklüyorsunuz?

vb.

vb.

vb

Muhtemelen uygulamanızı profillendirebilir ve uygulamanızdan bazı modülleri temizlemeye başlayabilirsiniz.

Görünüşe göre bu, bir uygulamanın birkaç kez yeniden dağıtılmasından sonra ortaya çıkabilir

Tomcat sıcak konuşlandırmaya sahip ancak bellek harcıyor. Arada bir konteynerinizi yeniden başlatmayı deneyin. Ayrıca, üretim modunda çalışmak için gereken bellek miktarını bilmeniz gerekecek, bu araştırma için iyi bir zaman gibi görünüyor.

3
OscarRyz

Bunu Eclipse IDE'de alıyorsanız, --launcher.XXMaxPermSize, -XX:MaxPermSize, vb. Parametrelerini ayarladıktan sonra bile, yine de aynı hatayı alıyorsanız, büyük olasılıkla Eclipse, yüklü olan JRE'nin buggy sürümünü kullanıyordur. Bazı üçüncü taraf uygulamalar tarafından Bu buggy sürümleri PermSize parametrelerini almaz ve bu yüzden ne ayarladığınız önemli değil, hala bu hafıza hatalarını almaya devam edersiniz. Yani, Eclipse.ini'nize aşağıdaki parametreleri ekleyin:

-vm <path to the right JRE directory>/<name of javaw executable>

Ayrıca, Eclipse'deki tercihlerde varsayılan JRE'yi doğru Java sürümüne ayarladığınızdan emin olun.

2
Hrishikesh Kumar

Benim için çalışmanın tek yolu JRockit JVM ile oldu. MyEclipse 8.6 var.

JVM'nin yığını, çalışan bir Java programı tarafından oluşturulan tüm nesneleri saklar. Java, nesneler oluşturmak için new operatörünü kullanır ve yeni nesneler için bellek, çalışma zamanında öbek üzerinde ayrılır. Çöp toplama, artık program tarafından referans alınmayan nesnelerin içerdiği belleği otomatik olarak boşaltma mekanizmasıdır.

2
Daniel

Ben de benzer bir sorun yaşıyordum. Mine JDK 7 + Maven 3.0.2 + Struts 2.0 + Google GUICE bağımlılık enjeksiyon tabanlı bir projedir.

mvn clean packagekomutunu çalıştırmayı denediğimde, aşağıdaki hatayı gösteriyordu ve "BUILD FAILURE" oluştu

org.Apache.maven.surefire.util.SurefireReflectionException: Java.lang.reflect.InvocationTargetException; iç içe istisna Java.lang.reflect.InvocationTargetException: null Java.lang.reflect.InvocationTargetException Sebep: Java.lang.OutOfMemoryError: PermGen alanı

Yukarıdaki faydalı ipuçlarını ve püf noktalarını denedim ama ne yazık ki hiçbiri benim için işe yaramadı. Benim için neyin işe yaradığı aşağıda adım adım açıklanmıştır: =>

  1. Pom.xml'inize gidin
  2. <artifactId>maven-surefire-plugin</artifactId> için ara
  3. Yeni bir <configuration> elemanı ve daha sonra aşağıda gösterildiği gibi <argLine> ileten -Xmx512m -XX:MaxPermSize=256m alt elemanı ekleyin.

<configuration> <argLine>-Xmx512m -XX:MaxPermSize=256m</argLine> </configuration>

Yardımcı olur umarım, mutlu programlama :)

2

"Onlar" yanlıştır, çünkü 6.0.29 kullanıyorum ve tüm seçenekleri ayarladıktan sonra bile aynı sorunu yaşıyorum. Tim Howland'ın yukarıda söylediği gibi, bu seçenekler yalnızca kaçınılmaz olanı ortadan kaldırdı. Her seferinde yeniden konuşmam yerine, hatayı vurmadan önce 3 defa yeniden konuşmamı sağlıyorlar.

2
Ross Peoples

Bu sorunu, aşağıdakileri yaparak da çözebilirsiniz:

rm -rf <Tomcat-dir>/work/* <Tomcat-dir>/temp/*

work ve temp dizinlerini silmek, Tomcat’ın temiz bir başlangıç ​​yapmasını sağlar.

1
dev

Herhangi biri netbeans aynı hata ile mücadele ediyorsa, o zaman işte nasıl düzelttim.

NetBeans'ta:

Servisler sekmesine gidin -> Sunucuda sağ -> Özellikleri seçin -> platform sekmesine gidin -> vm seçenekleri içinde -Xms1024m yazın

Benim durumumda, -Xms4096m verdim

İşte bir ekran görüntüsü:

 enter image description here

0
Satyadev