When to fix something that is "wrong" but works fine

Short version:

I wrote some code that is not done "the right way" because, when I wrote it, I didn't know how to do it. Now that I know how to do it "the right way", how do I decide how to fix it?

Longer version with details:

java.util.DecimalFormat is not Thread safe. I have what's essentially an immutable Description object that is used all over my code over many different threads. To fix this problem, I created a wrapper class SynchronizedFormatter that basically just wraps a lock around the methods of DecimalFormat that I use.

The right way to do this is to use a ThreadLocal . I didn't even know what that was when I wrote the code the first time. Is it worth it to fix? The synchronized version works just fine. How do I decide, about this in specific and about this situation more generally?

Also, I should mention that I do need to make other changes to this class for more important reasons than "I did this bit wrong the first time". That's what got me thinking - if I'm mucking about in this class anyway, maybe I should fix these other things that are on my bucket list. But then I fear slippery slope...

---

This is not a duplicate of When to refactor because Refactoring means:

Improving a computer program by reorganising its internal structure without altering its external behaviour.

This question talks about actually modifying the behavior of the code (e.g. using synchronized vs. ThreadLocal. Perhaps it should not be tagged refactoring.