Her şeyden önce, 8gb ram içeren bir kutum var, bu yüzden toplam hafızanın sorun olduğundan şüpheliyim. Bu uygulama, 6 gb veya daha düşük makinelerde sorunsuz çalışıyor.
Eclipse'de Yapılandırmaları Çalıştır'da "VM Argümanları" altında -Xmx3G kullanarak 3GB alan ayırmaya çalışıyorum.
1500 MB'den fazla ayırmaya çalıştığımda, şu hatayı alıyorum: “VM'nin başlatılması sırasında hata oluştu; -Xmx3G kullanılarak "nesne yığını için yeterli alan ayıramadı"
Burada neler oluyor?
Yanıtlar:
Bu makinede 32 bit jvm kullanıyor olabilir misiniz?
İşte bunu düzeltmek için yapılması gerekenler:
Go Start->Control Panel->System->Advanced(tab)->Environment Variables->System
Variables->New:
Variable name: _JAVA_OPTIONS
Variable value: -Xmx512M
Variable name: Path
Variable value: ;C:\Program Files\Java\jre6\bin;F:\JDK\bin;
Bunu uygun yolunuza değiştirin .
Bu aslında Eclipse'e özgü bir konu değildir; bu genel bir Windows üzerinde Java sorunudur. Bunun nedeni, JVM'nin Windows'ta bellek ayırma biçimidir; ayırma isteğini karşılamak için yeterli ayrı yığın olsa bile Windows'un sağlayamadığı bitişik bir bellek yığınını ayırmakta ısrar eder. Windows'un belleğini "birleştirmesine" yardımcı olan ve teorik olarak bu duruma yardımcı olacak yardımcı programlar vardır; ama onları gerçekten ciddiyetle denemedim, bu yüzden etkinlikleri hakkında konuşamıyorum. Bazen yardımcı olabileceğini duyduğum bir şey, Windows'u yeniden başlatmak ve diğer uygulamaları başlatmadan önce, büyük bir bellek parçasına ihtiyaç duyan Java uygulamasını başlatmaktır. Şanslıysanız, Windows henüz bellek alanını parçalamamış olmayacak ve Java, istenen bitişik bloğu alacaktır.
İnternette bir yerlerde bu konuyla ilgili daha teknik açıklamalar ve analizler var, ancak elimde herhangi bir referans yok.
Yine de faydalı görünen bunu buldum: https://stackoverflow.com/a/497757/639520
İlk olarak 32 bitlik JRE, ~ 1.5 Gb ram kullanamaz. Yani daha fazlasını istiyorsanız 64 bit JRE kullanın.
İkinci olarak, yeni bir JVM başladığında, bu, çalışan tüm JVM'nin -Xmx özelliğini toplar ve sistemde kendi -Xmx'inde çalışmak için yeterli bellek olup olmadığını kontrol edin, eğer yeterli değilse, hata oluşur.
Eclipse IDE'den Tomcat sunucusu ile Liferay kullanıyordum. Sunucu başlatıldığında tıklandığında aynı hatayla karşılaştım. Eclipse'den sunucuya çift tıklayın. Sunucu Genel Bakış sayfasını açar. -Xmx1024m -XX: MaxPermSize = 256m'den -Xmx512m -XX: MaxPermSize = 256m'den güncellenmiş bellek bağımsız değişkenleri. Sonra benim için çalışıyordu.
Eclipse'in aslında çalıştığını düşündüğünüz aynı JVM'yi çalıştırdığından emin olun. Web tarayıcınızda java kullanırsanız, muhtemelen son zamanlarda yüklenirse veya güncellenirse öncelikli olabilecek 32 bitlik bir sürümünüz vardır.
Kesinlikle emin olmak için, bu iki satırı eclipse.inidosyanızın en üstüne eklemenizi tavsiye ederim :
-vm
C:/Java/jdk1.6.0_27/bin
... makinemde C:/Java/jdk1.6.0_27/bin64 bit olduğunu bildiğim JVM'nin bulunduğu yer. binKlasörün orada olduğundan emin olun .
(Bir bonus olarak, Windows 7'de, bu aynı zamanda aslında "sekmeyi sabitlemenize" olanak tanır, bu yüzden bunu kendi kullanımım için yapmak zorunda kaldım)
eclipse.inibulabilirsiniz: wiki.eclipse.org/…
Bu, Yığın boyutu sorunudur. Senin düzenleyin .bat(Toplu dosyası). Yığın boyutu 1024 gösteriyor olabilir. 512 olarak değiştirin Daha sonra çalışması gerekir.
32 bit ve kullandığı JVM 64 bit olan Eclipse'i kullanırken de aynı problemi yaşadım. Eclipse'i 32 bit JVM'ye yönlendirdiğimde çalıştı
Sadece gradle'ın #önüne sembol koyun org.gradle.jvmargs=-Xmx1536m. Özellikler
# org.gradle.jvmargs=-Xmx1536m
Biraz geciktiğimi biliyorum ama işte cevabım geliyor:
Oracle'dan Java çevrimiçi Sürümünü (çevrimdışı 64 Bit olanı değil) yükledim.
JAVA_HOME ENV değişkenini ekledikten sonra, şimdi çalıştı!
Umarım yardımcı olabilirim :)
Muhtemelen yine de yanlış seçenekleri deniyorsunuz. Destekleyen hata günlüğüyle ilgili benzer bir hata aldım:
Java HotSpot(TM) Client VM warning: ignoring option PermSize=32M; support was removed in 8.0
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0
Benim durumum, yazılım henüz java 8'i desteklemiyordu (komut dosyası eski JVM argümanlarını kullanıyordu) ancak varsayılan olarak java 8'e sahiptim.