Non-static ThreadLocals

[swirlds-automation]

DataFileReader.ThreadLocalSeekableByteChannel extends ThreadLocal. A non-static seekableByteChannel of that type is instantiated for each DataFileReader, thus a new ThreadLocal is repeatedly created ("key", not value). ThreadLocals should be static.

In other places:

• CachingOperationProvider.context
• VirtualLeafRecordSerializer.dataOutputStream
• BucketSerializer.reusableBuckets
• VirtualHasher.hashBuilderLocal

[swirlds-automation]

Note that if per instance ThreadLocal is somehow deemed justified, then calling ThreadLocal.remove() in those instances is also required to avoid memory leaks in long living threads. Basically, this is an argument for redesign of the mechanisms relying on non-static ThreadLocals rather than fixing them. _{author:OlegMazurov, createdAt:2021-10-18T18:01:12Z, updatedAt=2021-10-18T18:01:12Z}

[swirlds-automation]

See also #5185 _{author:OlegMazurov, createdAt:2021-10-20T17:59:51Z, updatedAt=2021-10-20T17:59:51Z}

[swirlds-automation]

There are a few ThreadLocals in JasperDB / MerkleDb and VirtualMap, but all of them are static now. The only class from the list above that still uses non-static thread locals is CachingOperationProvider:

    private final ThreadLocal<HashMap<AlgType, Alg>> context = ThreadLocal.withInitial(HashMap::new);

_{author:artemananiev, createdAt:2023-02-22T00:13:12Z, updatedAt=2023-02-22T00:13:12Z}

[swirlds-automation]

_{migrated from: url=https://github.com/swirlds/swirlds-platform/issues/4046 author:OlegMazurov, #:4046, createdAt:2021-10-15T22:51:32Z, updatedAt=2023-02-22T00:13:29Z labels=Bug}