As a rule, if construction of a BufferedInputStream fails, you're
already sunk. Either something has gone seriously wrong or you're flat
out of memory and the VM is probably going to die in a moment anyway.
(Most of the times, OutOfMemoryError is very shortly followed by the VM
self-destructing, even if you catch it and try to recover somehow such
as by flush a load of caches and telling half your threads to die.)

There's an unfortunate tendency of Java not to run stably for a long
time -- it slowly exhausts its heap as any nontrivial app on average
creates new objects faster than the gc can clear old ones, even given
that the net amount of space tied up in live objects stabilizes. Once
that's happened, the VM tends to implode no matter what you do, so I've
taken to detecting low memory and gracefully exiting.

There seem to be some exceptions -- Eclipse itself is stable for days
and only slowly bloats and becomes less responsive, for example -- but
I don't know how they manage it. Even with the incremental garbage
collection in the newer VMs, the constant churn of small objects like
Strings and boxed primitives eventually overwhelms the gc's ability to
cope and kills the system.

It is likely that Eclipse gets away with days of uptime because a) when
it's unattended it's actually outright idle and b) when it's in use
most user activity results in modifying a variety of StringBuffers at
the backend and some disk files, rather than producing small object
churn.

Any network application, on the other hand, is constantly churning
Strings, URLs, various FooStreams and BarConnections, and all the lower
level stuff like Sockets and RequestHeaders that the programmer doesn't
even see touch their own code directly. Not to mention the assorted
Map.Entries and so forth involved in the data structures that
invariably hold the business logic's more persistent state, which for
these application types changes rapidly and continually even without
explicit user intervention...

A Web browser gives a simple example. A new, huge String is probably
involved in every page load, and some ad-encrufted sites will spawn as
many as 50 assorted Image instances *per pageview*. Multiply this for
any use of frames, throw in a URL and an assortment of I/O objects for
every remote object (such as an HTML file or image) loaded, and the
churn of List entries in the history, plus cookies and Christ alone
knows what else, and you're quickly looking at the browser blowing up
on the 1000th page load or so and getting noticeably slower by the
500th due to the gc.

Of course, you can internally reuse non-immutable objects (and that
includes strings and primitive types, if you use things like int[1]s
and StringBuffers in place of ints or Integers and Strings,
respectively) from a pool, but then you're simply copying gc
functionality and cluttering up your business logic with memory
management logic. Now you've got the explicit memory management and
accompanying logic clutter of C/C++ *and* the gc overhead to content
with -- also known as "the worst of both worlds".

I just hope that the evolution of the 1.6 beta is going to launch a
revolution in garbage collection that rescues Java from the mess that
every application creates of its heap in a relatively short amount of
time. Ultimately, I think these problems plague non-Java software too
-- particularly a problem I haven't even mentioned until now, heap
fragmentation -- and are responsible for a lot of flaky behavior and
crashes. Internal leaks of handles and memory are par for the course in
any Windows app, Java or otherwise, for instance. Fragmentation from
churn in small allocations and deallocations also isn't unique to Java.
And of course Java saves us from the worst memory management related
bugs, such as uninitialized data being used, or deallocated space being
referenced.

Ultimately, I'm not sure what the fix is. Even cleverer treatment of
small objects, perhaps, such as to give them their own heap in two
chunks, and when one is full start filling the other and defragmenting
and garbage collecting in the first. Move out and consolidate objects
that have persisted, to make room ... only I think the incremental gc
is already supposed to be doing something like this, and still my Java
apps tend to gradually grind to a halt...

Thomas Hawtin <usenet@tackline.plus.com> wrote or quoted in
Message-ID: <455a02fc$0$8733$ed2619ec@ptn-nntp-reader02.plus.net>:

( I assume that the above "if (out == null)" is mis-typed out.)

Why still wrong ?

Though an exception is thrown because of some reason,
'finally' block will be executed.

For the worst.
Even if the lack of memory happens, 'file' resource will be released.

Execute the following code.
Even if OOME is thrown, the lock of "a.txt" is released.

<code>
void test() throws Exception {
       
   OutputStream out = null;
       
   try {
       RandomAccessFile lock;
       File f;
           
       f = new File("a.txt");
       lock = new RandomAccessFile(f,"rw");
           
       if (lock.getChannel().tryLock() != null) {
               
           System.out.println("Lock OK");
       }
           
       f = new File("b.txt");
       out = new FileOutputStream(f);
       out = new TBufOutputStream(out);
           
       out.flush();
   }
   catch (Exception e){
           
       e.printStackTrace();
   }
   finally {

       if (out != null) {
               
           out.close();
       }
   }
}

class TBufOutputStream extends BufferedOutputStream {

   public TBufOutputStream(OutputStream out) {
       super(out);           
       long[] arr = new long[Integer.MAX_VALUE];
   }
}
</code>