Does OutputStream.write() has a memory leak on Linux?

Question

I write a piece of java code to create 500K small files (average 40K each) on CentOS. The original code is like this:
     package MyTest;
     import java.io.*;
     public class SimpleWriter {
public static void main(String[] args) {
  String dir = args[0];
  int fileCount = Integer.parseInt(args[1]);
  String content="@#$% SDBSDGSDF ASGSDFFSAGDHFSDSAWE^@$^HNFSGQW%#@&$%^J#%@#^$#UHRGSDSDNDFE$T#@$UERDFASGWQR!@%!@^$#@YEGEQW%!@%!!GSDHWET!^";
  StringBuilder sb = new StringBuilder();
  int count = 40 * 1024 / content.length();
  int remainder = (40 * 1024) % content.length();
  for (int i=0; i < count; i++)
   sb.append(content);
  if (remainder > 0)
   sb.append(content.substring(0, remainder));
  byte[] buf = sb.toString().getBytes();
  for (int j=0; j < fileCount; j++)
   String path = String.format("%s%sTestFile_%d.txt", dir, File.separator, j);
   try{
    BufferedOutputStream fs = new BufferedOutputStream(new FileOutputStream(path));
    fs.write(buf);
    fs.close();
   catch(FileNotFoundException fe)
    System.out.printf("Hit filenot found exception %s", fe.getMessage());
   catch(IOException ie)
    System.out.printf("Hit IO exception %s", ie.getMessage());
You can run this by issue following command:
  java -jar SimpleWriter.jar my_test_dir 500000
I thought this is a simple code, but then I realize that this code is using up to 14G of memory.  I know that because when I use free -m to check the memory, the free memory kept dropping, until my 15G memory VM only had 70 MB free memory left.  I compiled this using Eclipse, and I compile this against JDK 1.6 and then JDK1.7. The result is  the same.  The funny thing is that, if I comment out fs.write(), just open and close the stream, the memory stabilized at certain point.  Once I put fs.write() back, the memory allocation just go wild.  500K 40KB files is about 20G.  It seems Java's stream writer never deallocate its buffer during the operation.
I once thought java GC does not have time to clean.  But this make no sense since I closed the file stream for every file.  I even transfer my code into C#, and running under windows, the same code producing 500K 40KB files with memory stable at certain point, not taking 14G as under CentOS.  At least C#'s behavior is what I expected, but I could not believe Java perform this way.  I asked my colleague who were experienced in java.  They could not see anything wrong in code, but could not explain why this happened.  And they admit nobody had tried to create 500K file in a loop without stop.
I also searched online and everybody says that the only thing need to pay attention to, is close the stream, which I did.
Can anyone help me to figure out what's wrong?
Can anybody also try this and tell me what you see?
BTW, some people in online community tried the code on Windows and it seemed to worked fine.  I didn't tried it on windows.  I only tried in Linux as I thought that where people use Java for.  So, it seems this issue happened on Linux).
I also did the following to limit the JVM heap, but it take no effects
    java -Xmx2048m -jar SimpleWriter.jar my_test_dir 500000

Answer 1

Good point, I actually run cat /proc/meminfo. And I got the following.  Why I have so big of Inactive(file) allocation?
MemTotal:       15239492 kB
MemFree:           83424 kB
Buffers:           76012 kB
Cached:         13920152 kB
SwapCached:            0 kB
Active:           391104 kB
Inactive:       14181268 kB
Active(anon):     288124 kB
Inactive(anon):   288268 kB
Active(file):     102980 kB
Inactive(file): 13893000 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        500432 kB
SwapFree:         500432 kB
Dirty:           2568700 kB
Writeback:          6064 kB
AnonPages:        576292 kB
Mapped:             9884 kB
Shmem:               140 kB
Slab:             472340 kB
SReclaimable:     421692 kB
SUnreclaim:        50648 kB
KernelStack:        1192 kB
PageTables:         4132 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8120176 kB
Committed_AS:     835900 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       38908 kB
VmallocChunk:   34359687700 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:    15728640 kB
DirectMap2M:           0 kB
BTW, my test used up all the memory again, and free -m show this
             total       used       free     shared    buffers     cached
Mem:         14882      14805         76          0         80      13583
-/+ buffers/cache:       1142      13740
Swap:          488          0        488
Any hint what's going on?