Chunk ByteBuffer to soon recycled

[infeo]

In PR #125, the class BufferPool was introduced to reduce buffer allocations and reuse already allocated buffers for de- and encryption. The affected buffers are part of "Chunk" records, which represent a contigous memory area in a file.

A buffer is recylced, when:

• a chunk is saved to the ciphertextfile
• a chunk is loaded from the ciphertextfile and
• a chunk is evicted from the ChunkCache:
  

  cryptofs/src/main/java/org/cryptomator/cryptofs/fh/ChunkCache.java

  Lines 47 to 54 in ec170e7

  	private void removeChunk(RemovalNotification<Long, Chunk> removal) {
  	try {
  	chunkSaver.save(removal.getKey(), removal.getValue());
  	bufferPool.recycle(removal.getValue().data());
  	} catch (IOException e) {
  	throw new UncheckedIOException(e);
  	}
  	}

The third point (recycle on eviction) causes a severe bug. Imagine the following scenario:

• Small size of chunk cache (e.g., 5)
• Great number of concurrent reading threads (e.g., 100)
• File spanning over several chunks
• Random reading pattern leading to a low chunk cache hit rate

Low hit rate -> High number of cache evictions -> High recylce rate. But only because a chunk is evicted does not imply, the thread reading on the chunk has finished its operation. If the recycled buffer is selected to be filled again, the (still not finished) thread is reading wrong content.

[infeo]

To recycle the data buffer of Chunks, a synchronization mechanism is needed which ensures:

1. Once the chunk is evicted from cache, no new accesses to data can be made
2. the chunk keeps track of accesses
3. Only if the last access is "closed", the buffer is recycled

This would add another layer of complexity, hence, for now we decided to keep it simple and just synchronize threads on methods in CleartextFileChannel.