The Java Memory Model allows threads to cache copies of variables. This is done to improve performance.
If thread A writes to a field, that write may be cached.
Even if the cache is written to main memory, thread B may already have cached the value so may not see the update.
If the reader and writer threads use the same lock - or the field is volatile - then the JVM guarantees that the data will be published correctly. Otherwise, in general the reader may never see what the writer thread wrote, or may see writes out of order. [There are some further rules about final variables.]
Unfortunately this is quite difficult to test, as whether and when caching occurs depends on lots of factors.
So yes, adding volatile would fix this particular problem.
Or one could use final variables for all fields and use a constructor instead of clone.
That would be rather better.
But given that the rest of CSV is not thread-safe, I wonder whether it's necessary to make the format class thread-safe.