In C++ and C# when new not able to allocate enought memory it throws exception.
I couldn\'t find any information about new\'s behavior in Java. So what will happen
If you really do not have enough memory OutOfMemoryError is thrown. Also any exception may be thrown by constructor itself.
Assuming you specifically mean failure of the memory allocation, then it should throw OutOfMemoryError
Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.
Like all subclasses of Error
, it's usually a non-recoverable condition, even if technically you can catch it:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.
When Java cannot get enough memory to allocate an object you'll get an OutOfMemoryError.
In practice the exception can take quite a while to be actually thrown by the JVM. When faced to memory issue, the JVM will first try to garbage as much memory as possible. Depending on the JVM configuration (GC parameters and max heap memory), a GC cycle can take several seconds to several minutes with Xmx set to several gigabytes. Even worse, depending on the memory needed, the JVM can perform several GC cycles before throwing the exception.
When the exception is throw, it is processed as any uncaught exception. As such it will propagate to the top of the calling stack of the thread where the exception was raised. As the exception is uncaught, the thread will display a stacktrace on System.err
before dying. That's all. In a mono-threaded program this'll cause the program to exit. On a multi-threaded program, this thread death can free enough memory for the program to keep on running in an unstable configuration.
My recommendation if you're concerned about memory issue is that you should register and UncaughtExceptionHandler to kill your program when a memory issue arises as it is certainly better to stop your program than letting it working in an undefined state without anyone knowing.
You can read the following articles from Heinz Kabutz on the subject:
You can catch for OutOfMemoryExceptions but not recommended. However, unless it's a coding/design issue - the garbage collector should take care of managing the heap.
If you think you will be doing large amount of data processing and may run of memory then you can always check for the free space available before beginning execution (copied the code snippet from this link).
// Get current size of heap in bytes
long heapSize = Runtime.getRuntime().totalMemory();
// Get maximum size of heap in bytes. The heap cannot grow beyond this size.
// Any attempt will result in an OutOfMemoryException.
long heapMaxSize = Runtime.getRuntime().maxMemory();
// Get amount of free memory within the heap in bytes. This size will increase
// after garbage collection and decrease as new objects are created.
long heapFreeSize = Runtime.getRuntime().freeMemory();
A little more on OOME.
/*License - LGPL
<h3>Recovery from an OutOfMemory Error</h3>
<p>The JavaDocs for Error state, in the first sentence..
<blockquote>"An Error is a subclass of Throwable that indicates
serious problems that a reasonable application should
not try to catch."</blockquote>
<p>This advice has led to the fallacy that an OutOfMemoryError
should not be caught and dealt with. But this demo. shows
that it is quite easy to recover to the point of providing
the user with meaningful information, and advice on how to
proceed.
<p>I aim to make my applications 'unreasonable'. ;-)
*/
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
import javax.swing.JPanel;
import javax.swing.JLabel;
import javax.swing.JProgressBar;
import javax.swing.JOptionPane;
import javax.swing.JDialog;
import javax.swing.Timer;
import javax.swing.border.EmptyBorder;
import java.util.ArrayList;
/** A demo. showing recovery from an OutOfMemoryError.
Our options once an OOME is encountered are relatively
few, but we can still warn the end user and provide
advice on how to correct the problem.
@author Andrew Thompson */
public class MemoryRecoveryTest {
public static void main(String[] args) {
// reserve a buffer of memory
byte[] buffer = new byte[2^10];
ArrayList<Object> list = new ArrayList<Object>();
final JProgressBar memory = new JProgressBar(
0,
(int)Runtime.getRuntime().totalMemory());
ActionListener listener = new ActionListener() {
@Override
public void actionPerformed(ActionEvent ae) {
memory.setValue(
(int)Runtime.getRuntime().freeMemory() );
}
};
Timer timer = new Timer(500, listener);
timer.start();
JDialog dialog = new JDialog();
dialog.setTitle("Available Memory");
JPanel memoryPanel = new JPanel();
memoryPanel.add(memory);
memoryPanel.setBorder(new EmptyBorder(25,25,25,25));
dialog.add( memoryPanel );
dialog.pack();
dialog.setLocationRelativeTo(null);
dialog.setVisible(true);
dialog.addWindowListener( new WindowAdapter(){
@Override
public void windowClosing(WindowEvent we) {
System.exit(0);
}
} );
// prepare a memory warning panel in advance
JPanel memoryWarning = new JPanel();
memoryWarning.add( new JLabel(
"<HTML><BODY>There is not enough memory to" +
" complete the task!<BR> Use a variant " +
" of the application that assigns more memory.") );
try {
// do our 'memory intensive' task
while(true) {
list.add( new Object() );
}
} catch(OutOfMemoryError oome) {
// provide the VM with some memory 'breathing space'
// by clearing the buffer
buffer = null;
// tell the user what went wrong, and how to fix it
JOptionPane.showMessageDialog(
dialog,
memoryWarning,
"Out of Memory!",
JOptionPane.ERROR_MESSAGE);
}
}
}