Original subtitles

Instructor: In this video,

we're gonna cover lazy initialization.

Now by default, when your application starts,

all beans are initialized.

So it'll scan for all the components,

and all those components will be initialized.

So spring will create a new instance of each,

and make them available.

Now we can get some insights into this

by setting up some diagnostics,

or adding some println statements to our constructors.

So on our CricketCoach,

we'll add a println statement where we'll simply print

out the name of the class that we're processing on.

We'll do a similar thing here for baseball coach,

track coach, and also tennis coach.

And now, when we start our application,

then in the actual logs we should see In constructor:

BaseballCoach, PicketCoach, and so on.

Again, by the default when your application starts,

all beans are initialized and Spring will create an instance

of each and make them available.

Now we could make use of lazy initialization,

where instead of creating all the beans up front,

we can specify lazy initialization.

So, a bean will only be initialized in the following cases:

either when it's needed for a dependency injection,

or it is explicitly requested.

We simply add the lazy annotation

to a given class and those rules will come into play.

And here's a coding example: So for our track coach,

we'll say that our track coach is lazy,

(chuckling) so we'll make use of the lazy annotation.

This given bean will only be initialized

if it's needed for dependency injection.

If it's not needed, they won't create it.

In this coding example here,

with our demo controller and our constructor injection,

we're gonna inject the CricketCoach.

And when we run the application, we'll see the outputs

for our BaseballCoach, CricketCoach, and TennisCoach.

Since we're not injecting the TrackCoach

in this given scenario, then TrackCoach is not initialized.

So basically we're saying,

"Hey, don't create me unless I'm actually needed.

I don't wanna simply stand around and do nothing."

Now to configure the other beans for lazy initialization,

well, we'd need to add the lazy annotation to each class.

Not a big deal if we have a small number of classes,

but it turns into some real tedious work for a large number

of classes. I wish there was a way we could set up

a global configuration property,

just do it across the board.

And the answer's, yes, we can actually do that.

So in our application.properties file,

we can set this spring boot property,

spring.main.lazy-initialization=true.

All beans are lazy,

no beans are created until they're explicitly needed,

including our demo controller.

Once we access our REST endpoint of /dailywork out,

then Spring will determine the dependencies

for the demo controller and for the dependency resolution,

Spring will create an instance of the CricketCoach first,

and then create an instance of the DemoController

and inject the actual CricketCoach into the DemoController.

For more diagnostics, let's add a print line to our

DemoController constructor.

So here at DemoController,

we have the auto wire annotation here

System.out.printline In constructor,

print out the actual class name.

So again, for the dependency resolution,

Spring will create an instance of the CricketCoach first,

then create an instance of the DemoController,

and inject that into the actual DemoController.

All right, so kind of stepping back here and looking

at lazy initialization, as far as the advantages:

it only creates the objects as needed,

it may help you with faster startup time,

if you have a large number of components.

The disadvantages: If you have some web related components

like RestController, it will not be created until requested.

So the first time out, you'll have to kind of

create it first and then use it.

May not discover any configuration issues

until too late. And you also need to make sure

you have enough memory for all beans once created.

So with this lazy initialization feature,

it's actually disabled by default.

You should really profile your application

before configuring lazy initialization,

to see if the advantages will even help you.

And also, I wanna say, avoid the common pitfall

of premature optimization.

Because you could try and optimize something

that's really not even worth it.

All right, so just be aware of that,

if you're moving to thinking about lazy initialization.

However, I did want to cover it here,

just so you understand the concept,

and just so you understand the techniques.

Alrighty, so this is all really good stuff here.

Let's go ahead and move into the next video,

and let's do a code example.