concept singleton in category dependency injection

This is an excerpt from Manning's book Dependency Injection in .NET. Login to get full access to this book.

Within the scope of a single COMPOSER, a component with SINGLETON lifestyle behaves much like a SINGLETON. Each and every time a consumer requests the component, the same instance is served.

This is an excerpt from Manning's book Dependency Injection: Design Patterns Using Spring and Guice. Login to get full access to this book.

In this chapter we’ll talk about some of the general-purpose scopes: singleton and no scope. These are scopes that are universally applicable in managing state. We’ll also look at managing state in specific kinds of applications, particularly the web. Managing user-specific state is a major part of scoping for the web, and this is what the request, session, flash, and conversation scopes provide. We’ll look at a couple of implementations of these with regard to Guice and Spring and how they may be applied in building practical web applications. First, we’ll take a primer on scopes.

Figure 5.10. Memory usage for a singleton is constant compared to linear for no-scoped instances.

So how does scope widening feed this problem? Take the case of a singleton. A singleton is held by an injector forever, that is, for the injector’s (and usually the application’s) entire life span. Therefore, a singleton is never reclaimed during the life of an application. Singletons are generally reclaimed only on shutdown. If any nonsingletons are accidentally wired to a singleton through scope-widening injection, it follows that these objects are also (indirectly) held forever. Here’s a naïve example of a servlet that holds onto no-scoped instances on every request:

@Singleton
public class BadServlet extends HttpServlet {
    public final Provider<WebPage> page;
    public final List<WebPage> pages = new ArrayList<WebPage>();

    public void service(HttpServletRequest request,
        HttpServletResponse response) {
pages.add(page.get());

        pages.get(0).handle(request, response);
     }
}

copy

BadServlet is a frivolous example, but it serves to illustrate how a no-scoped dependency (WebPage) can be scope widened and held by a singleton, as shown in figure 6.14.

6.2.1. Singletons must be thread-safe

Singletons absolutely must be thread-safe—no exceptions. Any serious application has several threads of execution that are continually operating. They may be servicing different users, timers, remote clients, or any of a number of other purposes. A singleton-scoped key directly implies that only one shared instance of an object exists in the entire injector (and consequently the application). Multiple threads often end up accessing singleton instances and may even do so concurrently. Chapter 9 discusses the intricacies of threading and objects in detail (with a particular emphasis on Java’s thread and memory model).