I think there is another situation here that the proposed fix tries to address over here:

So, let's say there is a reader thread, that retrieved the file entry from the entries map.
And then before it loads (reads) the data from the file, there is a writer thread that is also operating in parallel.

The writer thread frees this entry (that the reader is attempting to load from the file).
Now, this writer tries to write a different key - value to the file. It picks up the same file entry that it recently freed up (and the reader is yet to read from the file). Now, the file entry carries data for a different key - value pair.

After this, the reader if finally able to read from the file. Now it ends up finding data for a different key.

This may explain the error that says "keyX" was expected, but "keyY" was found - and also the error about EOF exception because the boundaries for key length/value length won't co-incide.

Hopefully that throws more light on the issue.
As for the performance impact of this, I am not sure if it would be right to sacrifice data integrity for performance. Also, the locking is entry specific. So, updates for different key-value pairs should not get affected due to this.