title: Java - memory mapped file benefits
body: <p>I am struggling to see the benefits of the memory mapped file (buffer) in Java. here is how I see the approach in practice:</p>
  
  <p>We map chunks of file into main memory and deal with any writes/reads directly in memory, leaving OS to do the job of persisting the file into disk.</p>
  
  <p>Now, I wanted to contrast this with regular I/O and a few scenarios:</p>
  
  <ol>
  <li>Appending into a file</li>
  </ol>
  
  <p>In order to map the file into mem I have to read it in as a whole, to make overall modifications. The buffer size is the size of a file initially (let's say I do not know how much data I am about to write into the file). Now, in order to append to the file, I cannot do that, because the buffer is of limited size. So the most basic operation seems impossible to me. Also, reading in the whole file to append a small portion seems rather wasteful. So I guess regular I/O performs better in this scenario.</p>
  
  <ol>
  <li>Persisting changes</li>
  </ol>
  
  <p>In order to persist the changes i still need to flush them. Therefore, if I don't do this periodically I might have lost the changes in the main memory. This is the same idea with regular I/O streams, so no gain here either.</p>
  
  <ol>
  <li>Random changes</li>
  </ol>
  
  <p>This is where I can see this to work - replacing n bytes with other n bytes. Nevertheless, this seems rather unusual operation to have m characters being replaced by exactly m characters. we would rather have <code>Hello</code> and replace it with <code>Hi</code>. But we have a filled, fixed sized buffer, so that is not easy... Besides, it reminds me of <code>RandomAccessFile</code> with a better performance.</p>
  
  <p>Probably most of what I wrote is nonsense, but I will be happy to be told so, as for me atm the MemoryMappedBuffer seems hard and cumbersome (or even impossible) to use.</p>