diff --git a/core/src/main/java/com/google/bitcoin/core/Wallet.java b/core/src/main/java/com/google/bitcoin/core/Wallet.java
index 221cdf75..81be8355 100644
--- a/core/src/main/java/com/google/bitcoin/core/Wallet.java
+++ b/core/src/main/java/com/google/bitcoin/core/Wallet.java
@@ -254,37 +254,40 @@ public class Wallet implements Serializable {
saveToFile(temp, f);
}
- // This must be a static class to avoid creating a strong reference from this thread to the wallet. If we did that
- // it would never become garbage collectable because the autosave thread would never die. To avoid this from
- // happening the wallet posts a this pointer to us when it wants to get saved and we pick it up a short time
- // later. The delay allows coalescion of many rapid updates into occasional saves, and it means disk IO can be
- // done on a different thread which helps make UIs more responsive.
+ // Auto-saving can be done on a background thread if the user wishes it, this is to avoid stalling threads calling
+ // into the wallet on serialization/disk access all the time which is important in GUI apps where you don't want
+ // the main thread to ever wait on disk (otherwise you lose a lot of responsiveness). The primary case where it
+ // can be a problem is during block chain syncup - the wallet has to be saved after every block to record where
+ // it got up to and for updating the transaction confidence data, which can slow down block chain download a lot.
+ // So this thread not only puts the work of saving onto a background thread but also coalesces requests together.
private static class AutosaveThread extends Thread {
- private DelayQueue If delayTime is set, a background thread will be created and the wallet will only be saved to
* disk every so many time units. If no changes have occurred for the given time period, nothing will be written.
* In this way disk IO can be rate limited. It's a good idea to set this as otherwise the wallet can change very
- * frequently, eg if there are a lot of transactions in it or a busy key, and there will be a lot of redundant
+ * frequently, eg if there are a lot of transactions in it or during block sync, and there will be a lot of redundant
* writes. Note that when a new key is added, that always results in an immediate save regardless of
- * delayTime.
An event listener can be provided. If a delay >0 was specified, it will be called on a background thread * with the wallet locked when an auto-save occurs. If delay is zero or you do something that always triggers - * an immediate save, like adding a key, the event listener will be invoked on the calling threads. There is - * an important detail to get right here. The background thread that performs auto-saving keeps a weak reference - * to the wallet and shuts itself down if the wallet is garbage collected, so you don't have to think about it. - * If you provide an event listener however, it'd be very easy to accidentally hold a strong reference from your - * event listener to the wallet, meaning that the background thread will transitively keep your wallet object - * alive and un-collectable. So be careful to use a static inner class for this to avoid that problem, unless - * you don't care about keeping wallets alive indefinitely.
+ * an immediate save, like adding a key, the event listener will be invoked on the calling threads. * * @param f The destination file to save to. * @param delayTime How many time units to wait until saving the wallet on a background thread. diff --git a/tools/src/main/java/com/google/bitcoin/tools/WalletTool.java b/tools/src/main/java/com/google/bitcoin/tools/WalletTool.java index eb8c87e1..004e0ebb 100644 --- a/tools/src/main/java/com/google/bitcoin/tools/WalletTool.java +++ b/tools/src/main/java/com/google/bitcoin/tools/WalletTool.java @@ -339,9 +339,8 @@ public class WalletTool { return; } saveWallet(walletFile); - } else { - shutdown(); } + shutdown(); } private static void send(List