@Bean and @Configuration in Spring.

The @Bean annotation is used to indicate that a method instantiates, configures, and initializes a new object to be managed by the Spring IoC container. @Bean is most often used with @Configuration beans. Annotating a class with @Configuration indicates that its primary purpose is as a source of bean definitions.

While a name() attribute is available, the default strategy for determining the name of a bean is to use the name of the @Bean method.

@Bean was created to avoid coupling Spring and your business rules in compile time. It means you can reuse your business rules in other frameworks like PlayFramework or JEE.

@Configuration is meta-annotated with @Component, therefore @Configuration classes are candidates for component scanning and therefore may also take advantage of @Autowired/@Inject like any regular @Component.

Singleton design pattern in java

The singleton pattern is a design pattern that restricts the instantiation of a class to one object. Using following techniques we can make instantiation singleton.

1)Lazy initialization:

// Classical Java implementation of singleton

// design pattern

classSingleton

{

    privatestaticSingleton obj;

    // private constructor to force use of

    // getInstance() to create Singleton object

    privateSingleton() {}

    publicstaticSingleton getInstance()

    {

        if(obj==null)

            obj = newSingleton();

        returnobj;

    }

}

Singleton obj is not created until we need it and call getInstance() method. This is called lazy instantiation. Singleton obj is not created until we need it and call getInstance() method. This is called lazy instantiation.
The main problem with above method is that it is not thread safe.

Using synchronized makes sure that only one thread at a time can execute getInstance(). 
The main disadvantage of using synchronized every time while creating the singleton object is expensive and may decrease the performance. However if performance of getInstance() is not critical for your application this method provides a clean and simple solution.

2)Eager initializartion:

// Static initializer based Java implementation of

// singleton design pattern

classSingleton

{

    privatestaticSingleton obj = newSingleton();

    privateSingleton() {}

    publicstaticSingleton getInstance()

    {

        returnobj;

    }

}

Here we have created instance of singleton in static initializer. JVM executes static initializer when the class is loaded and hence this is guaranteed to be thread safe.

3)Double-checked locking:

If you notice carefully once an object is created synchronization is no longer useful because now obj will not be null and any sequence of operations will lead to consistent results. 
So we will only acquire lock on the getInstance() once, when the obj is null. This way we only synchronize the first way through, just what we want.

classSingleton

{

    privatestaticvolatileSingleton obj  = null;

    privateSingleton() {}

    publicstaticSingleton getInstance()

    {

        if(obj == null)

        {

            // To make thread safe

            synchronized(Singleton.class)

            {

                // check again as multiple threads

                // can reach above step

                if(obj==null)

                    obj = newSingleton();

            }

        }

        returnobj;

    }

}

This method drastically reduces the overhead of calling the synchronized method every time.


Singleton scope in spring

This is by default scope in spring . Only one shared instance of a singleton bean is managed, and all requests for beans with an ID that match that bean definition result in that one specific bean instance being returned by the Spring container , in short “one bean per bean id in a container“.

Suppose, I have a bean class Family. I have defined two beans from this class in bean definition, like:

<bean id="id1" class="com.example.Family"/> 
<bean id="id7" class="com.example.Family"/>

So when ever I try to get the bean with id “id1”,the spring container will create one bean, cache it and return same bean where ever referred with id1. If I try to get it with id7, another bean will be created from Sample class, same will be cached and returned each time you referred that with id7.

This is unlikely with Singleton pattern. In Singleton pattern one object per class loader is created . However in Spring, making the scope as Singleton does not restrict the container from creating many instances from that class. It just restricts new object creation for the same ID again, returning previously created object when an object is requested for the same id.