Bean instances are created by the IoC container. By default an ApplicationContext creates any beans it can when the IoC container starts. This is referred to as eager instantiation. BeanFactory's will not eagerly instantiate beans. Eager instantiation can help with performance by having all beans initialized on startup instead of creating them on demand. Beans can also be lazily initialized which means that their instantiation will be deferred to when they are actually retrieved. This might be done to save memory for infrequently accessed beans.

Beans are also singletons by default, but this isn't the same as the singleton design pattern. It means for each bean definition there will be only one instance of the bean created in each BeanFactory or ApplicationContext. Any request for the bean will be given the same instance.

Without a framework like Spring, using static variables and methods is an easy way for different classes to know about each other. Static variables could be used to store, transfer, or manage data between different instances of classes without a direct reference to each other. For example, let's say there is a class that initializes XSLT parsers and puts them into a Map. How would you be able to share these parsers with many different instances across your application? One way to do this would have been store the parsers in a static Map with static methods to get and set values on the Map. Now with Spring you can control whether or not a bean is a singleton in your Spring configuration and also use the configuration to register a bean. From XSLT parser example, you can now create the Map in Spring and inject the parsers into it. Then the Map of parsers can then in turn be injected into any other bean that needs to use it.

This can help address the overuse of static variables and the usage of the singleton design pattern. An important problem that results from designing classes this way can occur when sharing libraries in J2EE environments where EJBs and multiple webapps may need to share a library. Depending on where the library is loaded on the classpath, static variables can cause issues when different parts of the application are unable to have their own configuration requirements. It's also possible for standard applications to need two different configurations. Going back to the XSLT parser example, if the parsers were shared using a static Map what would you do if you had to have two different parser configurations? There may have been a default parser configuration, but now you need to leverage an alternate set of parsers while still leveraging all the existing code and even the keys the parsers were stored under. There are work arounds with a static Map (like creating another class to contain it), but if Spring is used to handle the creation of singletons then it will be much easier to create as many configurations as are needed. In this situation, two different sets of parsers can be created as Spring beans and injected where there are different parsing needs.