在什么情况下应该抓住java.lang.Error应用程序?
我正在开发一个需要大量内存的程序,我想在发生内存不足异常时捕获.我听说这是不可能做到的,但是如果在这方面有任何发展,我很好奇.
如果有更多对象分配请求进入之前有机会运行GC,JVM是否可以在不重启的情况下从OutOfMemoryError中恢复?
各个JVM实现在这方面有所不同吗?
我的问题是关于JVM恢复而不是用户程序试图通过捕获错误来恢复.换句话说,如果在应用程序服务器(jboss/websphere/..)中抛出OOME,我是否必须重新启动它?或者,如果进一步的请求似乎没有问题,我可以让它运行.
即使您已经尝试了一些减少内存使用的方法,捕获OutOfMemoryError是一个好习惯吗?或者我们应该不抓住异常?哪一个更好的做法?
try {
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 4;
bitmap = BitmapFactory.decodeFile(file, options);
} catch (OutOfMemoryError e) {
e.printStackTrace();
}
Run Code Online (Sandbox Code Playgroud)
谢谢
我是从C++来的Java.在C++世界中,我们注意异常安全,并注意,mutator可以在mutator本身抛出的异常或它委托给它的方法(最小,强,无抛出)时提供不同的保证.实现具有强异常保证的方法需要保证一些基本操作永远不会抛出异常.JLS声明哪些操作可以抛出哪种异常,但VirtualMachineError错误会带来问题.答曰JLS:
内部错误或资源限制阻止Java虚拟机实现Java编程语言的语义; 在这种情况下,
VirtualMachineError抛出一个子类的实例 .
JLS没有再说了VirtualMachineError."内部错误"意味着JVM中的一个错误,所以我对这种情况不感兴趣:面对JVM中的错误,所有的赌注都是关闭的.但是那个"资源限制"案例呢?是否存在因资源限制而保证永不失败的操作?
我来自c ++背景,我发现自己经常在java中这样做:
SomeClass sc=new SomeClass();
if(null!=sc)
{
sc.doSomething();
}
Run Code Online (Sandbox Code Playgroud)
我想知道的是,如果构造函数由于某种原因(例如可能没有足够的内存)而失败,那么变量sc中会出现什么.我找不到一个直接的答案,我担心我只是在浪费时间,因为如果新的操作员失败,程序会崩溃吗?
当Java虚拟机因内存不足而无法分配对象时抛出,并且垃圾收集器不再提供更多内存
Java说:
Error是Throwable的子类,表示合理的应用程序不应该尝试捕获的严重问题.大多数此类错误都是异常情况.
这听起来像听到:
如果你溺水,那就合理一点:你不应该试着向上游泳以保持头脑清醒.死亡通常是由异常情况引起的.
让我们想象一个运行服务的场景.出于某种原因,同一服务器上的另一个应用程序正在占用大量内存,从而导致服务中出现意外的OOM.尝试减少此服务的内存消耗以保持用户可用是不是一个坏主意?
或者是否有一些更基本的事情发生在JVM级别,阻止在抛出OOM后实现这样的解决方案?
try {
for(;;) {
s.add("Pradeep");
}
} finally {
System.out.println("In Finally");
}
Run Code Online (Sandbox Code Playgroud)
在try块中,jvm耗尽了内存,那么jvm在没有内存的情况下如何最终激活块?
输出:
In Finally
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
Run Code Online (Sandbox Code Playgroud) 'OutOfMemoryError':通常,当没有足够的空间来分配Java堆中的对象时,会抛出此错误.
GC(分配失败):分配失败"意味着分配请求大于年轻代中的可用空间.
这是否意味着当Young Generation内存已满(Minor GC)并且在完整GC中抛出"OutOfMemoryError"时,将抛出分配失败?
众所周知,有多种原因OutOfMEmoryError(见第一个答案).为什么只有一个例外情况涵盖了所有这些情况而不是继承的多个细粒度情况OutOfMEmoryError?
java ×9
exception ×4
jvm ×3
android ×1
bitmap ×1
correctness ×1
creation ×1
java-8 ×1
new-operator ×1
object ×1
subclassing ×1
try-catch ×1