Breaking legacy singletons

Question

We have packaged all our legacy code into a library and the new version of the code calls the legacy code as and when required; Though this approach is good, currently we are in a spot of bother as part of the legacy code has thread-unsafe singletons whereas the newer code calling them expect them to be thread-safe; we cannot afford to have synchronized blocks as that will clog the system when the load goes beyond certain number. Thought will take your inputs. Thanks!

Edit: These singletons are lazy ones without synchronized and double-checks on null instance:

 public static Parser getInstance() {
    Parser p = null;

    try {
        if (instance == null) {
            instance = new Parser(...);
        }

    } catch (Exception x) {
        ...
    }
    return p;
 }

and this code is at least 8 years old, we cannot fix them.

Answer 1

As was mentioned above in the comments, you should simply fix these classes (that's an easy fix!). That said, assuming you cannot touch this code, you can inherit from it and "override" (actually it's called "hiding" since the method is static) getInstance(). That would fix only the broken part and will maintain the same logic for the other parts.

BTW, if you decide to implement a singleton with the double null check, not only that you have to synchronize the innermost check, you also have to declare instance as volatile.

There are better ways to implement both lazy and eager singleton (static class, inner helper class and enum), make sure to asses all the options before you choose one.

Answer 2

if you have an object which is not thread safe, and the factory method returns a singleton, you have no choice but to synchronise.

you will need to change the factory method (or create a new one, if you can't edit the original code) which constructs new objects. if this is too expensive (and don't just assume it is, until you test it), look into which aspects of that are expensive and maybe some of the object's dependencies can still be singletons.

there is no magic solution here.

but.. i am about to tell you about a hack I did once when I was in a similar situation. but this is LAST RESORT and may not work in your case anyway. i was once handed a web application consisting of many servlets which contained both effectively global and local variables, as member variables. the guy who wrote it didn't realise the members of a servlet were single instance. the app worked in testing with 1 client but failed with multiple connections. we needed a fix fast. i let the servlets construct themselves as written. as the doGet and doPost methods were called, i got the servlet to clone itself and pass requests down to the clone. this copied the "global" members and gave the request fresh uninitialised members to the request. but, it's problematic. so don't do it. just fix your code. :)