Hello.
There are students in this lesson, we'll learn implementations of executive service interface and parents
lessons.
We learned what executive interface is and what executive service interface is to show them.
I had to use one implementation of executive service that today will require different implementations
of this interface and different use cases so that you'll know when to use one specific implementation.
Today will review fix reticule executer cash, streetball, single streetball, shadowless reticule.
As we will go over each executer one by one.
I will also explain what threat factor is and how you can use it during the installation of threats.
You understand what a threat starvation is and how to calculate a perfect number of threats for your
threat pool.
I'm going to show you formulas and we'll teach you how to calculate the blocking coefficient.
And as always, we are going to have a lot of examples to the source.
Code of all examples is in attachment to this lesson.
Let's start today.
We'll learn with you everything from official documentation and the code examples.
So let me start screen sharing.
I open source code of executor's class.
I believe you remember that we have factory mascots in this class that allows us to create instances
of different implementations of executive service interface and considerable amount of this factory
masses and level of details.
I would like to focus your attention on the difference between all of them and the main features rather
than on the source code of each particular executer.
So let's go one by one.
We will start from the top from the first factory mass.
This method is called new fixed thread pool and takes in value as method argument.
You can see that we reach an object of streetball executive type.
Let me open this one.
SWEPCO executive type extends Abstract Executive Service Zissis abstract class that is used by different
implementations of executive service, the common implementations of some methods that are appropriate
for all concrete classes that extends this abasic one.
And as you can see, abstract executive service implements executive service, which in turn implements
executer hope that the Iraqi is clear for you.
It will be similar for other executor's for our lesson today.
Let's now get back to Executor's.
So this massive new streetball grades and executive service that we use as fixed number of threats,
the fixed number of threats is passed to the method as methods argument.
The idea is simple.
All threats work on tasks in parallel, depending on your computer characteristics.
The number of threads running simultaneously and in parallel is different in case the more tasks than
current threats available to execute those tasks will wait in the queue until any threat from the pool
will be available again.
What will happen in case any other threats will be terminated because of the failure during the execution,
new one will be created and take its place to execute subsequent tasks.
Let's look at the example now.
I open the fixed thread, pull them across all executer examples that I will show you today.
Located in executor's package, you can find a link to the package was all executor's examples in attachments
to this lesson.
I create my Reppel executer, pay attention and create a pool for three threats.
Also, you can see that I cost object here because factoring in massive new fixed rate pool declares
that executive service will be returned and recommends us to operate with objects on this abstraction
level.
But we know that this concrete implementation of executive service will be used.
I need this to show your class specific matters that are absent in executive service.
After that, I submit for similar tasks to the executive service.
Each task sleep for one second and that's it.
I need the sleep for the sake of example, I call shut down MassArt here to not allow anyone to submit
any other tasks to this executive service after this line.
After that I principle size and Q's size.
These are class specific masses that are absent in executive service, but that will allow us to show
the future of fixed threat pool.
Let me run the program.
I run the program and I can see that pool size is three.
The number of threats that I have in my pool.
I passed this number to the factory Masset and number of tasks in queue is one.
That is because each task sleeps one second and the fourth task has no threats that would.
I said that's why it is in queue for the execution, but once these tasks are finished, one of the
threats is the last one.
Once all tasks are processed, UVM is finished.
That is because I call shut down MassArt, imperfect world.
I should call every termination Hendel potential interrupted exception and call shut down now.
But we discussed this in previous lesson and to not write a lot of code that doesn't directly relate
to the topic today, I will skip it.
But please make sure you learned well previous lesson and you know how to terminate multiple threats.
With the help of executive service, my students often ask me how to define ideal number of threats
to create infix threat pool.
I mean, what criteria we should use to define whether we need to create four, eight or chanceries
in pool.
It is not an easy question, but I will try explain it as simple as possible before calculating perfect
number of threats.
You should understand your limits.
And I'm talking not only about a number of CPU's in your computer.
I also want to draw attention to other limits.
For example, Zamunda limit on number of connections to a database.
Does it make sense to have one hundred twines threats that interact with database and have limited database
connection with ten connections?
Only the answer is obvious.
Or if a threat interacts with other system and sends a request to the APIs that can produce only a few
requests simultaneously.
This fact also needs to be considered because in the most pessimistic case, we may end up with reservation
state or even without of memory error.
What a threat.
Starvation.
Starvation describes a situation where Sweat is unable to gain regular access to shared resources and
is unable to make progress.
This happens when shared resources are made unavailable for long periods of grief threats.
And of course, another important factor to consider is number of years.
You can identify a number of tips like this call runtime static MassArt on runtime Closs.
You would get the reference to the runtime object and invoke available processers you will get enough
value.
This would be the number, of course, on your computer.
Be careful with this massive one you will work with container's this approach might provide it was wrong
information without any specific constraints.
A continuous process will be able to see the hardware on the operating system and it might happen at
your containerised application.
Supposedly is too coarse only, but your operating system has eight.
So just be careful when you rely on this value.
Here we have another variable executive service, too, and I want to show you that you can initialised
your executive service just like this in one line by passing the number, of course, to the masses.
But still, I mentioned the different factors that would impact our decision and that will help us to
answer what is a growing number of threats.
And it took great in my streetball.
Let's review a formula from book Java Concurrency.
In practice, number of threads equal to the number of available course multiplied by the result of
the next expression one plus the result of division between the wait time and service time.
Don't worry, it is not so scary as it looks like.
And the first glance, let's review it in detail and we need to understand first what is the wait time
and what is a service?
Time wasting time is a time spent waiting for inputs and outputs bound tasks to complete.
For example, this is not the amount of time you're waiting for a response from remote server.
And this is just one example because it might be not only input output tasks, but any tasks that makes
execution wait for some event and as examples might be getting monitor log.
What is service time?
Service time is a useful time.
The time spent being busy, for example, process HTP, response, data filtering or transformation,
etc. So dividing the waiting time by service time will get the result that is often called blocking
coefficient, a computation intensive task Hasbrouck and coefficient close to zero.
Now let's assume that we have four CPUs and let's substitute numbers in the formula with your data and
zero for blocking creation.
What result you have in this case?
The number of threads is equal to the number of available course.
If all tasks are computation intensive, then this is all we need.
And having more threats won't help us to improve performance because we respect the restriction of having
a limited number of CPUs.
Now, let's give you another example.
Imagine that our application process, different amount of data that is read from the server in the
Internet, you just send the request.
And the way the response was, the data program reads a bunch of data and processes it after that program,
reads another batch of data and processes it again, having the performance benchmark evaluation.
You know, that process of reviewing one batch takes two hundred milliseconds, for example, and time
of processing of this data.
Take 20 milliseconds.
Let's substitute numbers in our formula.
And in this case, following calculations in formula, we need forty four sets.
It seems to be a big amount of threats.
Let's think about it from another point of view.
You're going to have tasks that will be blocked waiting for two hundred milliseconds and what these
threats should do, just sitting and waiting.
They're doing exactly this thing, sitting and waiting.
And in the meantime, we have processors that are ready and happy to execute any other computations.
That's why in this particular case, with such weighting and service time, it is reasonable to have
44 phosphorescence a fixed rate pool.
There is a good practice to have separate executive services for each set of tasks.
In this case, each executive service may be configured accordingly for a specific class of tasks,
and one would have multiple executive services.
We need to adjust our formula by adding CPU utilization parameter to it.
What?
Well, you may be in target CPU utilization variable from zero to one inclusively where zero means that
streetball want to use processors at all and one means that streetball will use one hundred percent
of processors for time.
The formula becomes localizes.
In the similar case, and if I plan to grant only 50 percent of processers time to the batch data processing
and another 50 percent will be dedicated to other activities or other executive service, we are going
to have another result.
I add a zero point five to reflect targeted utilization and as a result, we have twenty two threats.
This number of threats you need to create in streetball to be efficient with these group of tasks.
Definitely life cases are different and it is not always so easy to calculate weighting and service
time for each task that you are going to create.
That's why these formulas are just a great starting point for you and hope that these formulas will
help you to understand the motivation to make a final decision regarding a number of threads in the
thread.
OK, now when you know, let's get back to Demo New Fix.
Red Bull Market is overloaded and has versions that accepts in value and threat factor what is a threat
factor.
Let's open the source code of this type.
Objects of a threat factory type are used to create new threats by giving implementation to the new
threat massive.
You can define the process and activities that are needed to be executed during the threat creation.
Let me explain to you with the example I open threat factor factory demo file.
I create a variable that would store WELI of number of threats in a threat posed.
I create executive service and have fixed number of threats input.
And when I create executive service, I call masses.
It also takes threat factor as my argument.
I pass object of the false threat factory type.
What is this?
This is my own implementation of threat factory interface.
For the sake of the demo, I decided to keep all types in one demo file to not navigate between the
multiple files of one example.
And here I implemented Nusrat Masset.
But why?
We need to override process of threat creation and control it is the motivation to implement custom
sweat factory is different.
You may need to perform some additional actions before creating a threat.
We need to create demon stress or for the debugging purposes, you need to name threats in a different
way than mine.
The different cases.
Why you want to control process of threat creation.
So you implemented a new threat.
Massive in this case.
I want to name threats for a different point.
You can see that I created atomic integer counter and threats by adding value of my counter, incrementing
it afterwards.
That's it.
Now, I said the same number of tasks I have for threats in goal and four tasks each task brings.
Threatening to consult you can submit is a callable or runnable.
Don't pay attention to a new threat.
Must be acceptant Runnable.
This is not directly connected in new executer you create a threat.
Threats are created during the executive servicing utilization in this case and once threats are created,
I submit tasks that will be implemented by these threats.
Tasks may be easier of type runnable or callable.
I keep command here.
Example with Kobel task submission.
Just in case you would like to uncommented and try once you would get the source code.
Let's run this example and in console you might see the threats are different from default.
This proves that Masset of the threat factor was used to create threats in the threat pool.
Is that clear?
Great.
Let's move on now.
Let's look at all the implementations of executive service interface.
Probably remember that when we just first time created executive service, I used cached thread pool.
Let's investigate this one in the source code of executive class.
You can see that when I call New Castrato, I also creates red radical executer just with different
arguments.
So as you may already understand, these mass return us different versions of pre configure thread Thredbo
executer to understand better.
What is the difference between cash Stratego and fix reticle.
Let's compare constructor arguments that are used during the initialization of threat to execute executer
object.
You can see that in cash streetball first two arguments are zero and max integer.
These arguments are responsible to set Corpuz size and maximum pool size.
What is Corpuz size does.
This is a number of threats to keep in the pool, even if they're idle.
How it is different from fixed threat pool infix threat pool equate specific number of threats.
The number ipass as method argument is a.
Plus size and the maximum size, the argument is a keep a lifetime when the number of threats is greater
than the core.
This is the maximum time that excess idle threats will wait for new tasks before terminated.
We can see that they keep a lifetime in cash.
Pool is 60 seconds and infix threat pools.
This value is zero milliseconds.
And the first argument is a cue that is used to store tasks before they're executed.
We can see that in cash throughout threat pool, we use synchronous cue and then fixed threat pool.
We use link, lock and key to what conclusion we may do based on these constructor arguments, these
arguments.
This means that the Casarett pool might grow without bounds to accommodate any number of submitted tasks.
But when the threats are not needed anymore, they will be disposed of after 60 seconds of inactivity
when it might be useful.
For example, when we have a lot of shirtsleeve and tasks in application in a synchronous queue, each
in search operation must wait for a corresponding remove operation.
So we can say that pairs of insert and remove operations always occur simultaneously.
That means that the queue never actually contains.
Annison is as good for most cases.
As I said before, it is good in case we have a lot of shirtsleeve and tasks, but this is not always
the case.
In other cases, using of threat cached pool may impact performance of our application in case with
cash streetball.
Each new task will create a new threat if all existing threats are busy and and reflect potential issues
that might happen during the high load where you have to fix pool.
In the best case, we may get a reservation situation at worst out of memory error.
This is something that you need to consider when you decide to use pre configured threat pool executer
created by new Casarett Pool Factory MassArt.
Let's look at example now I open cash thread pool demo file here.
We have similar example to one we have in the fixed thread pool demo file.
The only difference is that I use different factor Massud from executor's class I call new cache streetball
method.
I submit for tasks and print, pool size and size.
And as we expected, pool size will be equal to the number of submitted tasks in this case because each
thread has leape inside.
And by the moment new task is submitted, there are no available threats and new threat is created and
queue size will be equal to zero because we are synchronous queue inside the threat to execute.
Does it make sense?
And also there is a factory method that takes threat factor as method argument so you can use it when
needed.
That's it.
Regarding the cash threat pool, let's continue the next factory method.
Probably not worse for a separate demo you can call new single thread executer this massive returns
and executive service that manages one thread.
If this single thread terminates due to a failure during the execution prior to shutdown, a new one
will take its place if needed to execute subsequent tasks.
Tasks are guaranteed to execute sequentially, and no more than one task will be active at any given
time.
Additionally, this Red Bull executer is decorated with an immutable wrapper so it can be reconfigured
after creation.
Let's return now skinless Red Bull.
Executer we have to factor masses in executor's class that allows us to create executor's service of
this type ZAYA News kidlets red pool within the parameters.
It describes a number of course, threads and overloaded masses that takes that factory as an additional
argument in the source code.
We can use it on an instance of scandals.
Reppel exactly the type.
Let's open it and investigate this type.
As we can see from the time declaration, it extends red executer and implements kidlet executive service
interface, which in turn extends executive service interface.
We need to understand what new behavior is introduced by scheduled executive service.
Basically for new methods are introduced on Vermonter's cattle methods it takes is a random object.
This method allows us to run a task once after a specified delay.
Also cattle at fixed rate mass that allows us to run a task after a specified initial delay and then
run it repeatedly with a certain period.
The period argument is a time measured between the starting times of the tasks.
So the execution rate is fixed.
Schedule was fixed, the.
A.M. is similar to scheduled at a fixed rate in that it would be the difference as a given task, but
the specified delay is measured between the end of the previous task and start of the next task.
Its execution rate may vary depending on the time it takes to run any given task.
Let's open skidoos, read to them clause to review, quote, examples with this executer.
The first example just shows us how to execute some task after initial delay.
I create executer calls Macit.
I just want to bring threatening to cancel after one second delay.
This all tasks that I want to schedule.
Let's run this program in console.
We can see that threatening has been printed.
This is how simple you must kill task for execution.
Now I open scattered pull them two in this file we have them off schedule at fixed rate and schedule.
With delay I create executer and then Wolk's cattle at fixed rate.
Initial delay is five hundred milliseconds and after that start of each new task in each one second
after seven seconds waiting, we shut down our executive service.
I printer separator here and after that I create new executer and then walks schedule with a fixed delay.
I am going to run the program and I'd like you pay attention to the fact that these two masses will
work slightly differently because they track the same interval a little bit differently from start of
one task to start of another task and from finish off one task to start off another task, I intentionally
added sleep in each task.
In this case, we may notice how in the first case, new task is executed each second, and in the second
case, each task is executed approximately one and a half second because interval is measured between
end of the one task and start of another task.
And each task has sleep inside.
I run the program and you can watch the result and feel the difference.
Can you see the difference?
Hope that with this example it is clear HouseCalls Reticule executive works.
Also, we have similar factory method, but just for executer with one thread you can use three single
threads candidate executive factory method to create similar.
Executer was one thread.
You can see that there is a wrapper here that exposes only the scheduled executive service methods of
a scheduled executive service implementation and service over overloaded method that takes threat factor
as method argument removed almost all factory methods to create different executive services.
We still need to learn for doing framework to understand how, for example, works.
That's why we'll review new works to improve Masset in the next lesson.
That's it for today.
Let's review what we have learned today in this lesson.
In this lesson, we learn different implementations of executive services.
We learn thread pool, executive class and how to create a fixed threat pool and cache threat pool.
Now, you know the difference in these pro configurator threat pools.
Also, you know the formula and the rules that will help you to calculate the ideal number of threats
to create in the threat pool.
Also, we learned how to work with threat factory after this lesson.
You know how to work with a single threat pool and scandalous threat pool.
Executer that's all what I have for you for this lesson.
Thanks a lot for your attention.
Have a great day and see you in the next lesson.