Deep copy of a BufferedInputStream about cloning HOT 4 OPEN

BufferedInputStream uses your original stream to fetch data. If you used a FileInputStream, chances are that the cloned FileInputStream contains a cloned FileDescriptor but with the same FileDescriptor.fd. This must be the low level OS file handler. So the behaviour of it will be unexpected. Maybe you already read the file using your "bis" BufferedInputStream and the cloned returns -1 (since it is the same low level file).

from cloning.

Yes, I did already read the file using 'bis'. There is no way to clone an already read BufferedInputStream?

from cloning.

Cloner can't clone the native file handler.

Also cloning non-java pointers can lead to jvm crashes, so I would recommend avoiding it. I think in this case it is better to just re-open the file if you need to re-read it.

from cloning.

The stream read operation is fundamentally based on the file handler which gets by the long field handle in class FileDescriptor. It means different streams have different file handlers(even if two streams point to the same file), so the handle field of every stream instance should be different.But clone operation will make two streams have the same file handler, it causes two streams share one read() operation, when one of the stream reaches the end, the other stream's reading operation will return -1.

from cloning.