[bisq-network/bisq] Fix temp file path memory leak (#3817)

[Steven Barclay]

The internal `java.io.DeleteOnExitHook` uses a `LinkedHashSet` of paths to delete files at when the JVM exits. However, since there is no way to remove entries from the set, it leaks memory when calling `deleteOnExit()` for every new temp file created by `FileManager.saveToFile`. To avoid this, try to reuse temp file names (using one per `FileManager` instance).

`FileManager.saveToFile` appears to be called on average around every 2s, and this probably leaks around 36 + _length_ * 2 bytes for the String object, 36 bytes for the hashtable node and maybe around 10 bytes for the table entry, or 82 + _length_ * 2 ~= 236 bytes for a typical temp file path length on Windows - about 10MB per day.
You can view, comment on, or merge this pull request online at:

  https://github.com/bisq-network/bisq/pull/3817

-- Commit Summary --

  * Remove redundant locking from FileManager.saveToFile
  * Reuse temp file names to fix a memory leak caused by deleteOnExit()

-- File Changes --

    M common/src/main/java/bisq/common/storage/FileManager.java (26)
    M common/src/main/java/bisq/common/storage/FileUtil.java (9)

-- Patch Links --

https://github.com/bisq-network/bisq/pull/3817.patch
https://github.com/bisq-network/bisq/pull/3817.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/3817
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191220/6e0e76ef/attachment.html>