It's not an anti-pattern. Anti-patterns have some property that makes it seem like a good idea, which leads people to do it on purpose; they're planned as patterns and then it goes terribly wrong.
It's also what makes for debates as to whether something is a pattern, an anti-pattern, or a commonly mis-applied pattern that does still have uses in some places.
This is just wrong.
To add a bit more.
This code is superstitious, or at best a cargo-cult practice.
A superstition is something done without a clear justification. It may be related to something real, but the connection is not logical.
A cargo-cult practice is one where you try to copy something that you've learnt from a more knowledgeable source, but you are actually copying the surface artefacts rather than the process (so-named for a cult in Papua New Guinea who would make aircraft control radios out of bamboo hoping to make the WWII Japanese and American planes come back).
In both of these cases there isn't any real case to be made.
An anti-pattern is an attempt at a reasonable improvement, whether in the small (that extra branching to deal with that extra case that has to be dealt with, that leads to spaghetti code) or in the large where you very deliberately implement a pattern that either is discredited or debated (many would describe the singletons as such, with some excluding a write-only - e.g. logging objects or read-only e.g. configuration settings objects - and some would condemn even those) or else where you're solving the wrong problem (when .NET was first brought out, MS recommended a pattern for dealing with disposing when you had both unmanaged fields and disposable managed fields - it does indeed deal with that situation very well, but the real problem is that you've got both types of field in the same class).
As such, an anti-pattern is something that a smart person who knows the language, problem domain and available libraries well will deliberately do, that still has (or is argued to have) a downside that overwhelms the upside.
Since none of us start out knowing a given language, problem domain and available libraries well, and since everyone can miss something as they go from one reasonable solution to another (e.g. start storing something in a field for a good use, and then try to refactor it away but not complete the job, and you'll end up with code like in the question), and since we all miss things from time to time in learning, we have all created some superstitious or cargo-cult code at some point. The good thing, is they're actually clearer to identify and correct than anti-patterns. True anti-patterns are either arguably not anti-patterns, or at have some attractive quality, or at least have some way of luring one into them even when identified as bad (too many and too few layers are both uncontroversially bad, but avoiding one leads to the other).
MethodA
orMethodB
causeMethodA
orMethodB
to be called in any way (andbar
is used again, in the case of thebar.{A,B}()
being the offender) you have similar issues even without any concurrency.