Static/global/singleton are all basically the same idea, and have the same downsides.

using a singleton need to check if the instance is allocated.That demand this check eveytime we need to use the singleton.
The alternative is to use a static

Foo& GetFoo()
{
  static Foo foo;
  return foo;
}

Foo& GetFoo()
{
  static bool initialized = false;
  static byte foo[sizeof(Foo)];
  if( !initialized )
  {
    initialized = true;
    new(foo) Foo();
  }
  return *(Foo*)foo;
}

Singletons, static members, and global variables are all the same thing wearing different trousers.

The goodness of the design is not inherent to the tool, it's about how you use it. Static members have their place in certain circumstances, as do globals. (I leave out singletons on purpose, but we've had that argument a million times and I will not have it repeated here.)

You haven't really described why you think this is a necessary design decision, but based on sheer probability and the fact that you mentioned a singleton to begin with, I'd wager decent money that your specific use case is "bad" design.

Hi,using a singleton need to check if the instance is allocated.That demand this check eveytime we need to use the singleton.
The alternative is to use a static but recently i have listen that using static is not good because of multithreading.

You haven't really described why you think this is a necessary design decision, but based on sheer probability and the fact that you mentioned a singleton to begin with, I'd wager decent money that your specific use case is "bad" design.

The bad design is, obviously, having to check on access whether something has been initialized: it would be equally bad for non-singleton objects. The actual alternative is not between a singleton and a static variable, but between silly "on demand" initialization (like in Hodgman's code snippet) and a correct object lifetime (ensuring that static variables are initialized before access, like in Java where the first reference to a class pauses client code to load the class and run its static initialization).

Using any kind of shared mutable state is not going to play nice with multi-threading. Even if you fix initialisation problems, you still need to deal with the thread safety when accessing and modifying the state itself.

This is regardless of whether you expose such state as a global, a static value, a singleton, or even passing a reference.