Singleton's other members

Question

My question is broad, so I've split in two parts, and tried to be as specific as I can with what I know so far.

First part

A singleton holds a private static instance of itself. Some questions about singletons:
1. Should it's members also be static, or does that depend on the requirements?
2. If the answer to 1. is unequivocally yes, then what would be the point of having a private instance variable to begin with, if all members belong to the class?
3. Is the private instance needed because the JVM needs a referable object (THE singleton) to hold on to for the length of its (JVM's) life?

Second part

There is a requirement to make multiple concurrent remote calls within a tomcat hosted web application (the app utilizes GWT for some components, so I can utilize a servlet for this aforementioned requirement if a good solution requires this). Currently, I create an executor service with a cached thread pool into which I pass my callables (each callable containing an endpoint configuration), for each individual process flow that requires such calls. To me it would make sense if the thread pool was shared by multiple flows, instead of spawning pools of their own. Would a singleton holding a static thread pool be a good solution for this?

Answer 1

One note is that it is important to distinguish between the concept of a singleton (a class/object that has only a single instance) and the design pattern which achieves this via a class holding a single static instance of itself accessible in the global static name space. The concept of a singleton is frequently used in designs, the implementation of it via the singleton design pattern, however, is often frowned upon.

In the below, singleton is used to refer to the specific design pattern.

Part 1

1. A Singleton's members do not need to be static, and usually are not.
2. See 1.
3. A singleton (design pattern) requires an instance to itself in order to return that instance to users of the singleton, as well as keeping a reference to itself active to avoid garbage collection (as you suggest). Without this single instance, the object is essentially not an implementation of the singleton design pattern. You can create a class for which you only create a single instance and pass this class around where it is required (avoiding the global static namespace), and this would essentially be a recommended way to avoid using the singleton pattern.

Part 2:

Sharing your thread pools is probably wise (but depends on your requirements), and this can be done in a number of ways. One way would be to create a single pool and to pass this pool (inject it) into the classes that require it. Usual recommendation for this is to use something like Spring to handle this for you.

Using a singleton is also an option, but even if your thread pool here is encapsulated in a singleton, it is still generally preferable to inject this singleton (preferably referenced via an interface) into dependent objects (either via a setter or in their constructor) instead of having your objects refer to the singleton statically. There are various reasons for this, with testing, flexibility, and control over order of instantiation being some examples.

Answer 2

1. A Singleton's members need not be be static.
2. Invalidated by answer to point 1.
3. The instance of itself that the singleton need not be private either. You need an instance stored to a static member (public or private) if you have any other non-static member on the singleton. If there is any non-static member(it depends on your requirement) , then you need an instance to access that member(yes, JVM needs a referable object if the member is non-static)

Answer 3

1. Singleton member doesn't need to be static
2. Look at point 1
3. Singleton instance must be static (of course) and must be accessed by a static method; in addiction must have a private constructor to prevent new instance to be created

---

public class SingletonNumber10 {  
  public static SingletonNumber10 getInstance() {
    if(null == instance) {
      instance = new SingletonNumber10(10);
    }
    return instance;
  }
  private int number;
  private static SingletonNumber10 instance;
  private SingletonNumber10(int number) {
    this.number = number;
  }
  public int getNumber() {
    return this.number;
  }
  public static void main(String[] args) {
    System.out.println(SingletonNumber10.getInstance());
    System.out.println(SingletonNumber10.getInstance());
  }
}

Answer 4

A singleton holds a private static instance of itself. 

Not always, in fact, that's not even the best way to do it in Java.

public enum Director {

   INSTANCE;

   public int getFive() {
     return 5;
   }

}

Is a perfectly valid singleton, and is far more likely to remain the only copy in existence than a class that holds a private static instance of itself.

1. Should it's members also be static

No, the members should not be static, because then there is no need for a class, and therefore no need for that class to be a singleton. All static routines are subject to code maintenance issues, similar to C / C++ functions. Even though with singletons you won't have multiple instances to deal with, having the method off of an instance provides you with certain abilities to morph the code in the future.

2. If the answer to 1. is unequivocally yes.

It's not, so no need to answer #2.

3. Is the private instance needed because the JVM needs a 
   referable object (THE singleton) to hold on to for the
   length of its (JVM's) life?

No, the private instance is needed because you have to have some ability to determine if the constructor was called previous to the access. This is typically done by checking to see if the instance variable is null. With race conditions and class loader considerations, it is incredibly difficult to make such code correct. Using the enum technique, you can ensure that there is only on instance, as the JVM internals are not subject to the same kinds of race conditions, and even if they were, only one instance is guaranteed to be presented to the program environment.

There is a requirement to make multiple concurrent remote calls within
a tomcat hosted web application (the app utilizes GWT for some components,
so I can utilize a servlet for this aforementioned requirement if a good 
solution requires this). Currently, I create an executor service with a cached 
thread pool into which I pass my callables (each callable containing an endpoint
configuration), for each individual process flow that requires such calls. To 
me it would make sense if the thread pool was shared by multiple flows, instead
of spawning pools of their own. Would a singleton holding a static thread pool be
a good solution for this?

It depends. What are the threads in the pool going to be doing? If it's a thread to handle the task, eventually they will all get tied up with the long running tasks, possibly starving other critical processing. If you have a very large number of tasks to perform, perhaps restructuring the processing similar to the call-back patterns used in NIO might actually give you better performance (where one thread handles dispatching of call-backs for many tasks, without a pool).

Until you present a second way of handling the problem, or make more details of the operating environment available, the only solution presented is typically a good solution.

PS. Please don't expand on the details of the environment. The question submission process is easy, so if you want to expand on the second part, resubmit it as an independent question.