@alixwar You're right - that's a false positive.
I would however slightly simplify the code using the pattern from The "Double-Checked Locking is Broken" Declaration, avoid the local variable:

public final class Foo {
    private static volatile Foo myFoo;

    public static Foo getInstance() {
        if (myFoo == null) {
            synchronized (Foo .class) {
                if (myFoo == null) {
                    instance = new Foo();
                }
            }
        }
        return myFoo;
    }
}

But since the singleton you are using, is static (there is only one Foo instance), there is an even simpler way:

public final class Foo {
    private Foo() {}

    private static class FooSingletonHelper {
        private static final Foo INSTANCE = new Foo();
    }

    public static Foo getInstance() {
        return FooSingletonHelper.INSTANCE;
    }
}

See also Java Singleton Design Pattern Best Practices with Examples

@adangel Thanks for the pointers! One detail: the Bill Pugh Singleton Implementation that you recommend triggers another rule violation:

private static final Foo INSTANCE = new Foo();

Instantiates through a private constructor from outside of the constructors class (pmd:AccessorClassGeneration)

@adangel Thanks for the pointers! One detail: the Bill Pugh Singleton Implementation that you recommend triggers another rule violation:

private static final Foo INSTANCE = new Foo();

Instantiates through a private constructor from outside of the constructors class (pmd:AccessorClassGeneration)

I encountered the same situation, when using a static inner class singleton.
(pmd:AccessorClassGeneration)

@alixwar @liu78778 long story short: the solution is to change the visibility of the constructor from private to package-private. It's slightly more open, but is what the compiler ends up doing anyway (through a synthetic constructor).

Now, having said that, I'd strongly recommend you revise wether you actually need the AccessorClassGeneration rule. The rule (along with the companion AccessorMethodGeneration) warn when you access a private field / method / constructor from an inner class (or viceversa). This access is impossible in Java, so the syntax sugar is translated by the compiler into:

1. creating an "accessor" method (typically named access$001 and so forth) with package-private visibility, delegating to the private method / working as a setter / getter for the private field; or simply a package-private constructor delegating to the private one.
2. editing the caller to call the new accessor method instead of the original private one

The extra indirection introduced by this method has 2 negative effects:

1. a slightly worst performance (minimal, and typically removed by the JVM after warmup)
2. a greater number of methods in the class (something you should not even care about, except for some very specific situations, such as aiming for single-dexing an Android application).

I personally never adopt this rule outside of an Android project myself.

@jsotuyod Ah, I get it, thank you very much for your replay