YT YouTube2Text

YouTube2Text → Transcripts → 🔔 Java / Full Stack Developer | 2–8 Years Experience | Spring Boot | Microservices | ReactJS | Git

🔔 Java / Full Stack Developer | 2–8 Years Experience | Spring Boot | Microservices | ReactJS | Git — Transcript

by Insights Instructor · 6,084 words · 882 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Can you please tell me about yourself?
0:02>> Yeah. Hi. So, I am a software developer
0:05with around 3 years of experience. Uh
0:07mostly I have worked on the backend
0:10development and uh my core technical
0:13skills basically include uh Java, Spring
0:16Boot and microservices and I have
0:18hands-on experience in designing and
0:20developing REST APIs and working with
0:23databases and also integrating different
0:26services. And uh apart from that I also
0:29have some basic exposure to front- end
0:31technologies like react and all. So
0:33basically this helps me to understand
0:36like in application flow. So uh so I
0:39have worked in agile environment also
0:42and activate and actively participate in
0:44code reviews as well and apart from that
0:47I also do participate in the uh
0:49production issues resolution whenever
0:51the testers uh raises the bug and uh
0:54debugging the issues also. So yeah, so
0:57this is all about myself and uh my daily
0:59activities. Yeah.
1:00>> Okay. So can you tell me about your
1:02current project?
1:04>> Yeah, I am currently working on an
1:05e-commerce application uh that is built
1:08using the spring boot and microservices
1:10architecture. So the system consists of
1:11multiple services such as product,
1:13order, user and notification services.
1:16And uh in that my responsibilities
1:18include developing and maintaining
1:20backend APIs and implementing business
1:22logic and handling databases interaction
1:24and improving the performance and
1:26scalability. So the application
1:29basically supports the features like
1:31product search, order processing and not
1:33notifications and uh that is designed to
1:36handle the high traffic uh during the
1:38peak sales. So uh we use the scalable
1:41and usually coupled services in order to
1:43handle all this. So yeah so this is what
1:45is about my project in very brief.
1:47>> Okay. So can you explain how ReactJS is
1:51integrated with the back end and can you
1:54describe the complete end toend flow
1:57when a client makes any request?
2:00So can you tell me the whole flow?
2:02>> Uh yeah sure. So in our application,
2:05ReactJS is used for the uh front end and
2:09spring boot is used for the back end. So
2:12let me explain in toend flow using the
2:14like let's say simple example for the
2:17fetching the product details. So first
2:19user opens the application in the
2:21browser and uh react application is
2:24already loaded in the browser and it
2:27shows the UI. So when the user clicks on
2:29the button like uh view products so
2:32reactjs and API call using the tools
2:35like uh fetch or exio so the API request
2:39is sent from the browser to the backend
2:42rest api endpoint. So that is exposed by
2:44the spring boot basically. So for
2:46example we can have like something like
2:49uh forward/ a like localhost at80 and
2:52then forward/ uh api and products. So
2:56something like that. So it will
2:57basically try to get the request and the
3:00request goes through the security
3:02filters if authentication is enabled. So
3:04the spring boot controller receives the
3:06request and then it forwards it to the
3:09service layer. So there the business
3:10logic is handled. So whatever the
3:12business logic we have written based on
3:14that it will be further processed. So
3:16the service layer then calls the
3:17repository layer and it fetches the data
3:19from the database. So once the data is
3:21retrieved then the back end sends the
3:23response back to the react application
3:25in JSON format. So then react receives
3:28this response and it updates the uh like
3:31state and rerenders the UI to display
3:34the product list uh on the screen. So
3:36all this happens like without reloading
3:38of the page and giving better experience
3:40to the user. So this is what is like
3:43whole end to end flow how react and
3:46spring boot work together when like any
3:48client makes a request. So yeah.
3:51>> Okay. Can you tell me how does React
3:53handles the API errors which is coming
3:56from the back end?
3:57>> Yeah, React itself does not handle the
4:00API errors automatically basically. So
4:02we handle errors in the code when the uh
4:05like when we make an API call. So when
4:08reject call say backend API using the
4:11fetch or exio so we use try catch block
4:15or an error uh like block. So error call
4:19back will be there. So if the back end
4:21returns like error we may have like 400
4:25401 404 or maybe 500. So we can catch
4:29the error in react. So after catching
4:32the error like uh we show a proper error
4:35message to the user like uh maybe
4:37something went wrong or unauthorized
4:40access based on the access code what we
4:42receive. So based on that we can uh
4:45write some specific message and we can
4:48show the fallback UI like uh maybe error
4:51message or uh toast notification or
4:54alert also we can show and for the
4:57authentication errors like maybe 401 or
5:00403 we usually redirect the user to the
5:03login page. So uh we also stop loaders
5:06or spinners uh so the UI uh does not get
5:10stuck. Yeah. So in short like React
5:12handles the back end API errors by
5:13catching them from the API call itself
5:16and uh we saw the meaningful uh message
5:19or notification or alert uh as per the
5:22requirement. So yeah.
5:24>> Okay. So what will happen if the backend
5:26API is very slow or time out happens
5:30from the UI?
5:32>> Yeah. If the back end API is slow or
5:34timeout happens then the React
5:36application like keeps waiting for the
5:38response and during this time you we
5:40usually show a loading indicator or a
5:43spinner so the user like knows that
5:46something is happening and if the API
5:48takes too long time and it uh like um uh
5:52we will have the some time out will be
5:54there so the loading will appear for
5:56some specific time only and uh if
5:58timeout happens then react catches the
6:00error in the API call. So when uh
6:03timeout is uh or when the timeout
6:06happens or uh or slow response happens
6:09then we saw some user friendly messages
6:11like maybe uh like request is taking too
6:14long uh please try again or something uh
6:16like or maybe we retry the request
6:19automatically or allow the user to retry
6:21manually also. So it all depends on the
6:24again scenario best thing. So yeah.
6:26>> Okay. Do you know what is COR is and
6:30have you ever faced this issue?
6:33>> Yeah, CO is basically Yeah, that stands
6:36for the cross origin uh uh R for
6:39resource sharing. So that is cross
6:41origin resource sharing. So it is a
6:44browser security rule. So that basically
6:47controls whether a front-end application
6:50can call a backend API from different
6:52domain port or protocol. So yeah we have
6:56faced this issue. So it usually happens
6:58when the like react front end and spring
7:02boot back end are running on a different
7:04ports or domains. So for example uh
7:07whenever we are using react so some so
7:10it will be suppose it is up on the local
7:12host uh 3000 port and if uh we have a
7:16backend uh spring boot application so
7:18that might be running on the local host
7:20at80. So in this case the browser blocks
7:23the request for the security region and
7:25it shows the CS error. So to fix this we
7:28allow the front end uh origin in the uh
7:31back end by we use like add of cross
7:34origin annotation in the spring boot or
7:36we configure the course uh globally in
7:39the back end configuration. So once the
7:41back end allows the front end origin
7:43then the browser allows uh the request
7:46to go through. So yeah, so in the very
7:48like in the simple words we can say like
7:50cos is a browser uh restriction and we
7:53fix it by properly configuring the back
7:56end to allow the like trusted front end
7:59applications. So yeah.
8:01>> Okay. So suppose an API gets updated.
8:05Okay. Whatever you were working with
8:08earlier version so it got updated. So
8:10then how do you handle API versioning?
8:14So front end user are not impacted so
8:18that old request also should be keep on
8:21working along with the new request.
8:23>> Yeah. So when an API needs to be updated
8:26so we do not change the existing API
8:28directly because like it can break the
8:31front end that is uh already using it.
8:34So instead we create a new version of
8:36the API and we keep the old uh version
8:39running. So for example, let's say we
8:41have old API maybe API and then we say
8:45like forward/ maybe V1 then products and
8:49we can have the new API uh like API
8:52forward/ V2 and then products. So this
8:55way we can identify okay V_sub_1 is the
8:57older version and V2 is the newer
8:59version. So the existing front end
9:01continues uh using the V1 without any
9:04issues and the updated front end can
9:06start using the V2. So once all front
9:09end users are migrated to the new
9:11version then we like uh we mention the
9:14documentation for the deprecated this
9:17old API that was a v1 and when we are
9:22completely we we are not using this v1
9:25then we remove it later on. So this way
9:27like front end changes do not break and
9:30backward compar compatibility is also
9:32maintained. So yeah so that is how we
9:34are doing it.
9:35>> Okay. So how do you secure the API when
9:39react is calling the spring boot?
9:42>> Yeah, we secure APIs uh using the JWT
9:46based authentication. So that we are
9:48using currently. So React sends a token
9:50with like every request and spring boot
9:53like validates the token before allowing
9:55the access. So yeah.
9:57>> Okay. Can you explain bit more?
10:02>> Yeah. So whenever the user logs in from
10:05the react application then the
10:08credentials are sent to the spring boot
10:10back end. So after successful
10:12authentication the back end generates a
10:14JWT token and returns uh it to the
10:17react. So React stores this token
10:19securely and uh sends it with the uh
10:23every API request in the authorization
10:25header and spring boot intercepts each
10:28request and violates the token and uh
10:30checks user roles and permission. So if
10:33the tokens is valid then the request is
10:36processed and if it is missing expired
10:38or like invalid then the back end sends
10:41and authorize an error. Okay. [snorts]
10:44So we also use like https and like this
10:49uh we discussed like cos configuration
10:51and rule based access control to further
10:54secure the APIs. Yeah. So that is how we
10:56are using the JWT.
10:57>> Okay. So suppose in the react
11:00application the page load time is taking
11:04little bit more time than the actual
11:06one. So how do you improve it?
11:10>> Yeah. So we can improve the page load
11:12time by uh maybe uh lazy loading
11:16components. So that reduces the bundle
11:19size and minimizes the unnecessary API
11:21calls. So to improve the page uh load
11:26time in React application, we first
11:28reduce the initial bundle size by using
11:30the uh code splitting and lazy loading.
11:34So only in that case required components
11:37are loaded whenever needed. So we
11:39optimize API calls by uh fetching only
11:42necessary data and using the caching
11:46where it is possible. So we also use uh
11:49like u uh use memo and call back. So all
11:53these are there to avoid unnecessary
11:56rerenders. So that is like uh
11:57memorization. So that is also we can use
12:00and other improvements we can also do
12:03like uh maybe we can enable the browser
12:05caching also and we can avoid the like
12:08heavy computation on UI thread and all
12:10and also we can compress or optimize the
12:12images. So these are also the few hacks
12:16we can say so that we can use to uh make
12:19the UI load faster. So yeah so these are
12:23the things we can do. Yes.
12:26>> Okay. Can you tell me what happens
12:29behind the scene when you start a spring
12:32boot application?
12:34>> Yeah, when a spring boot application
12:37starts then it first runs the uh main
12:40method and then it launches the spring
12:42boot framework and spring boot then
12:45creates the application context. So that
12:47acts as the spring container we can say.
12:51And next it loads the environment
12:53properties from uh like we have files
12:56right applic.
13:00So from there it will read the
13:02environment uh properties and along with
13:04system and environment variables also.
13:06Uh after that it performs the class path
13:09scanning and to identify the components
13:13uh configuration and dependencies. So uh
13:16spring boot uh like we have like at the
13:18rate of uh spring boot start application
13:21right. So that is the reason why this
13:22all this uh configuration and
13:25dependencies or scannings are done. Then
13:27spring boot then applies auto
13:29configuration based on the dependencies
13:31available in the class path and it
13:33creates and initializes or all required
13:37beans and uh then it resolves their
13:39dependencies and manage their life
13:41cycle. So once the bean is ready then
13:45spring boot starts the embedded web
13:47server whatever the it is embedded with
13:49uh that is spring boot application and
13:52uh after that it executes uh command
13:55line runner or application runner logic
13:58and the application becomes like ready
14:01to handle incoming request. So this is
14:04what will happen behind the scen.
14:06>> Okay. Is it possible that spring auto
14:10wire we have annotation right that may
14:13sometime fail even when the bean exist.
14:17Is it possible?
14:18>> Yeah it is possible.
14:20>> Okay. Can you explain in what scenarios
14:24and more about it?
14:26>> Yeah. So uh like uh add that uh auto
14:29wired can fail due to multiple beams of
14:32the same type or missing component scan
14:35or like bean side uh bean life cycle and
14:38visibility issues. So even if a bean
14:41exist then order of to auto may fail in
14:44some situations like suppose we have
14:46multiple bean of same type. So can throw
14:50like no unique bean definition exception
14:52something like that. So so that can be
14:55fixed by add of qualifier or primary. So
14:58that concept comes in. So we have to use
15:01these annotations to tell uh spring that
15:04which one will be used uh like taken
15:06into consideration first. And also like
15:08bean is suppose not in the component
15:11scan path then also it can fail. So if
15:14the bean is defined outside of the
15:16package uh that spring scans then also
15:20it won't be detected. So automatically
15:22it bean will not be there into the uh
15:25memory. So it it will fail and uh then
15:30it does not work on static fields also
15:33because spring injects dependencies only
15:35into bean instances. So that is also
15:39might be the one reason also sometimes
15:42uh like the bean is requested before it
15:45is fully created or initialized then
15:48also it may fail sometimes.
15:50>> Okay. Okay. So can you tell me the
15:52scenario when bean got called before
15:55initialization?
15:57>> Uh I actually did not face it but it may
16:01happen. So uh like a bean can be called
16:06before full installation when it is uh
16:09accessed during a startup such as inside
16:12a constructor or a static block or early
16:16uh like life cycle phase. So one common
16:19scenario is using the uh like let's say
16:24bin A depends on bin B and again B is
16:27still the uh in the process of being
16:30created. So B and A again tries to use
16:34the bin B uh inside the constructor.
16:38Okay. So at this time B is not fully
16:41initialized. So calling the method using
16:44like it can give the null pointer
16:46exception. So uh that scenario may
16:49happen that I know but yeah I have not
16:51faced it in my uh uh project.
16:55>> Okay. So why we cannot use at the rate
16:58of autowired on a static fields.
17:02>> Yeah we cannot use it because a static
17:04fields belongs to class not to the bean
17:06instances. So spring injects uh
17:09dependencies only into bean instances.
17:12So it does not work on the static.
17:14>> Okay. Can you tell me the difference
17:16between application context and bean
17:19factory?
17:21>> Bean factory is the basic spring
17:24container responsible only for creating
17:28and managing beans. So it uses lazy
17:31initialization which means that the
17:33beans beans are created only when uh
17:36they are requested. So it provides core
17:39dependency injection features but very
17:42limited enterprise support. So
17:44application context in the other hand
17:46more advanced container we can say so
17:48that extends bean factory and provides
17:51the additional features required for the
17:54enterprise application. So it supports
17:56like in eager initialization. So that
17:58means that the most uh uh beans are
18:01created at startup itself. So yeah, so
18:04in the real world uh spring boot
18:06application application context is more
18:09preferred because it offers more
18:11functionality and better performance
18:13monitoring and that is easier to work
18:15with the uh like compared to the bin
18:16factory. Yeah. So this uh this context
18:19like this also supports like AOP and uh
18:23like uh some internalizations also
18:26supported. So those things are there but
18:28it is not there into the uh basic bean
18:31factory.
18:32>> Okay. So can you tell me one thing why
18:35doesn't spring roll back a transaction
18:38when a checked exception is thrown and
18:42how can this behavior be changed? You
18:44tell me that also. Yeah, by default
18:47spring transactional roll back uh
18:49transactions only for unchecked
18:52exceptions. So like for runtime and
18:55error. So the design follows the
18:58assumption that unchecked exceptions
19:00indicate programming or system failure
19:04that should uh invalidate and uh
19:07transactions.
19:08So checked exceptions on the other hand
19:11are treated as business or coverable
19:14exceptions. So spring assumes the uh
19:18application can handle them without
19:21requiring a roll back. So if a roll back
19:24is required for a checked exception then
19:27it must be explicitly uh configured
19:30using a roll back or uh uh roll back for
19:34class name attributes in like or address
19:37of transactional. So suppose uh like we
19:40have added transactional and uh we the
19:43bracket let's say we say roll back for
19:45exception.class. So that will force roll
19:48back for all exceptions. And if we say
19:51roll back for like any custom exception
19:54dot class so it will target that
19:56specific uh checked exceptions only. So
19:59that basically behaves uh behavior gives
20:02uh developers like uh good control over
20:05the uh transaction boundaries and avoid
20:08unnecessary road uh rollbacks and
20:10expected business scenarios.
20:13[snorts]
20:14>> Okay. Coming to microservices. Can you
20:16tell me in short what are microservices?
20:20>> Yeah, microservices is an architectural
20:23style where an application is divided
20:25into a small uh independent services and
20:29each service focuses on one business
20:31capability such as payment order or user
20:35management. So these services can be
20:37developed, deployed uh and scaled
20:41independently without uh affecting
20:43others. So yeah so that is what is a
20:46microservices
20:47>> and why do you think microservices are
20:50different from monolithic architecture?
20:52>> Yeah. So in a monolithic architecture
20:54the entire application is like one
20:57single unit with one uh deployment.
21:00Okay. And uh any small changes requires
21:04the redeploying the whole application.
21:06But in microservices each services is
21:08separate. So it will have its own uh
21:10database and uh uh all the uh
21:13dependencies also. So it will will be
21:15related to the data specific
21:16microservices and only. So the teams can
21:19update and deploy uh like uh these
21:22microservices independently. So the so
21:24that reduces the risk and downtime for
21:27this whole application. So that is what
21:30is the difference between uh these two.
21:32>> And how does microservices
21:36communicate with each other? Yeah,
21:38microservices usually communicate using
21:40REST APIs over HTTP for synchronous
21:44calls and for asynchronous communication
21:48they use message brokers like Kafka or
21:51Rabbit MQ. So yeah, so this basically
21:55helps services stay loosely coupled and
21:58it improves the system reliability.
22:02>> Okay. And what is service discovery?
22:05Yeah, service discovery basically allows
22:07microservices to find each other
22:10automatically at runtime and since
22:13services can scale up or grown then
22:17their IP addresses uh change uh
22:20frequently so we have tools like ureka
22:24so that helps uh register and locate
22:27services dynamically so that's what is
22:30the service discovery
22:31>> and how do you handle transactions
22:34across the microservices.
22:36>> Yeah, traditional databases uh
22:38transaction
22:40are not suitable for microservices. So
22:43state system is uses uh like saga
22:46pattern. So there each step has a uh
22:50like compensating action. So this ensure
22:53the data consistency across multiple
22:55services.
22:56>> Okay. Can you tell me what is the
22:59difference between double equal to and
23:02equals method in Java?
23:04>> Yeah, sure. So double equal to basically
23:06it compares the memory address like uh
23:10whether two references point to the same
23:13object and dot equals method compares
23:15the content or value inside that object.
23:18So like for example two different string
23:20objects with the same text. So that may
23:23return false like uh with whenever we
23:26are using double equal to but uh it will
23:29return true whenever we are using dot
23:30equals. So yeah so that's the
23:32difference.
23:34Okay. So let's say suppose you created a
23:38custom class called employee and it has
23:42fields like ID and name. Okay.
23:46And you again created two different
23:49employee objects with the same ID and
23:51name values. Right? So now when you
23:56compare them using dot equals so it is
23:59suppose returning false even though the
24:02data inside the both object is the same.
24:05So can you tell me why is this
24:06happening?
24:09>> Yeah. So since uh we are using only
24:12equals. So this happens because we did
24:15not override dot equals method uh in the
24:18custom class. So by default dot equals
24:20method from the object class is used. So
24:23the default uh implementation compares
24:26the memory address not the actual value
24:28inside the object. So even if the two
24:30objects have the same data so they are
24:33stored in different memory locations. So
24:36that's why the that equals uh returns
24:38false. So it will behave just like you
24:40can say like double equal to. So yeah so
24:44that's the reason why it is not equal.
24:46>> Okay. So what problem can this cause in
24:50case of h has set or hashmap?
24:52>> Yeah. So if we do not override equals
24:55and has code then it can create like
24:58issues uh in the h has set and hashmap.
25:01So uh het does not allow duplicate
25:05values but it uses uh high has code
25:07method first and then equals to check
25:10the duplicates. So if equals is not
25:12overridden in that case two objects with
25:15the same uh data will be like treated as
25:18a different objects and both will be
25:20stored in the same hset also. So
25:22duplicates will exist even though
25:24logically they are same. So uh that's
25:27what will happen in the hashet and in
25:28hashmap also like uh like hashmap uses h
25:32has code okay and it to find buckets and
25:35equals it it will use it uses to compare
25:38the keys. So if it is not overridden
25:41then uh two keys with the same data will
25:44be treated as different keys and also
25:47retrieval may fail. So we may not be
25:51able to get the value using the
25:52logically equal key. So that's what will
25:54happen. Yeah.
25:55>> Okay. And now suppose another scenario.
25:58So suppose you use a custom object as a
26:02key in the hashmap. Okay. And after
26:05inserting the object into the map, you
26:08modify one of its fields that is used in
26:12the hash code calculation.
26:14Okay. Now when you try to retrieve the
26:18value using the same object, so it
26:20returns null. So can you tell me why
26:23this happened? Uh yes. So when we insert
26:26a key into a hashmap, so Java uses the
26:30hash code method of that key to decide
26:33which bucket to store uh it in. Okay. So
26:36if the hash code changes after insertion
26:40then the object remains uh in the old
26:43bucket but when we try to retrieve it
26:46then hashmap calculates the new hash
26:48code and it searches in a different
26:50bucket also. Okay. So it cannot find the
26:54object. So even though the key is
26:55physically present inside the map, it
26:58becomes uh like uh you can say logically
27:01unreachable. So basically data cannot be
27:03retrieved and it will look like kind of
27:06data is lost and uh duplicate entries
27:09may get inserted. So ultimately it may
27:12cause the memory leaks because the old
27:14key is still uh I mean there in the map
27:16but it cannot accessed properly. It
27:18cannot be accessed properly. So we can
27:20say like a system behavior also becomes
27:22unpredictable in this point of time.
27:25Yeah.
27:26>> Okay. So can two unequal objects have
27:29the same hash code?
27:32>> Yeah it it can be there. So basically it
27:35is called hash collision. So we apply
27:39multiple methods to avoid this kind of
27:42collision and we take some measures
27:46to avoid that h collision.
27:49Okay. So what measures do you take to
27:52avoid that h collision?
27:54>> Uh actually we cannot completely avoid
27:56the h collision but we can reduce them
27:59by writing a good hash code method and
28:02using the proper key design. So uh that
28:06way we can do that but yeah we cannot
28:09still guarantee that it the collision
28:11will never occur.
28:14>> Okay fine. So can you tell me the
28:17difference between arraylist and link
28:19list?
28:21>> Yeah sure. So array list basically uses
28:23a dynamic array internally. So it is
28:27fast for random access. So we can get by
28:30index in case of array list and link
28:33list uses a doubly link list internally.
28:35So uh it is faster for insertion and
28:38deletion in the middle but link list
28:41uses more memory compared to array list.
28:44So yeah, so that's the difference
28:46between array list and link list.
28:49>> Okay. And if linked list is faster for
28:52insertion, then why is array list is
28:55more commonly used?
28:57>> Because in real application we do more
29:00like read operations like we do mostly
29:03get by index thing and all we do that.
29:06So we do insertion in the middle we do
29:08very like less. It is not frequently
29:11used but wherever we have the scenario
29:14like we have to do insertion in the
29:16middle and all in that case we can go
29:18for that link list otherwise we use the
29:20array list. So array list basically
29:22provides O of one random access while
29:25linked list takes O of N times to access
29:28the by index. So uh that's why the
29:32there's a difference between the speed
29:34and that's why we use mostly uh like
29:36array list but it's all depends on the
29:38scenario
29:40and in real applications like uh uh
29:43scenario of get by index comes more
29:47compared to the insertion in the middle.
29:49>> Okay. So if you need to frequently
29:51remove elements from the beginning of
29:54the list so which is better?
29:58uh if we have to remove from the
30:00beginning link list we should use
30:02because array list will sift like all
30:04elements right so that will be costly
30:07but it won't be the case in case of link
30:09list so linked to be the better bit here
30:12>> okay so what happens when multiple
30:15threads increment a shared counter
30:19>> uh if multiple thread uh increment a
30:22shared counter then uh race conditions
30:25uh occur so which can lead to incorrect
30:28or inconsistent result.
30:31>> Okay. Can you explain bit more?
30:35>> Yeah. So when multiple threads try to
30:37increment the same shared counter at the
30:40same time then problems can occur
30:42because the uh increment operation is
30:44not atomic. So incrementing like counter
30:48plus suppose if you're using so that is
30:49actually uh a three-step process we can
30:52say. So first of all it reads the
30:54current value then add one to it and
30:56then write the new value back. Okay. So
30:59if two threads read the same value at
31:02the same time then both may read for
31:04example five and both increment it to
31:07six and both will uh like write back six
31:11again. So instead of becoming seven the
31:14value becomes six six. So this is called
31:17a race condition because the threads can
31:20uh and threads are racing to update the
31:23same variable basically. So that is why
31:26it is called race condition. So it will
31:28ultimately lead to data consist uh
31:31consistency and uh unpredictable system
31:35behavior and all. So yeah.
31:39>> Okay. And how can you fix it?
31:42>> Yeah. To fix this we can use
31:43synchronized keyword and atomic integer
31:46also we can use. So yeah so these we can
31:49do.
31:50>> So why doesn't volatile fix it this
31:52problem?
31:53>> Yeah volatile basically insures the
31:55visibility of changes across threads but
31:58it does not makes operations atomic. So
32:02when we mark a variable as volatile then
32:04it guarantees that any change made by uh
32:08one thread is uh immediately visible to
32:10another thread. So the value is always
32:13uh read from main memory not from the
32:16thread cach but volatile does not make
32:19uh uh like compound uh uh operations
32:23atomic. So uh even if the like variable
32:27is volatile so two threads can read the
32:30same value at the same time it can
32:31increment it also and it can write back
32:34the same result. So the final value can
32:36still be incorrect. So yeah
32:38>> suppose you deployed your spring boot
32:41application multiple times on a server.
32:44So let's say for example on Tomcat. So
32:46after every deployment you suppose
32:49notice the heap memory
32:51keeps increasing and it never fully
32:54comes back down. So even after
32:57restarting the application inside the
32:59same server memory uses keep on growing.
33:02So can you tell me what might be the
33:04reason and why it is growing? Yeah. So
33:07this usually happens because some
33:08objects from the previous uh deployment
33:10are not getting uh garbage collected.
33:13That might be the reason. And in Java uh
33:17application servers uh every deployment
33:20creates a new class loader. So if
33:22something from the old deployment is
33:24still uh being referenced then the old
33:27class loader cannot be uh garbage
33:29collected. Okay. So this is basically
33:32called a class uh loader leak. So uh
33:36there might be multiple reasons again.
33:38So for example static variables if we
33:42store large objects into static fields
33:45uh then so these basically stay in the
33:47memory as long as the class is loaded.
33:49So if not cleared properly they prevent
33:51garbage collection and also like there
33:55might be reason like we if we use
33:57suppose thread local and and we forget
34:00to remove values like remove method so
34:03it may hold references to the old object
34:06that might be the another reason and
34:08also the caching so in memory caches
34:11like custom maps uh eh cache radius and
34:14all so if it is not clear during then
34:19also it can uh uh like retain the old
34:22references. So these are the few uh like
34:26uh reasons I am able to think of and
34:28also like if suppose uh in case of
34:31database connection so if connection
34:33pools are not closed properly then also
34:36they may cause the memory and so these
34:39might be the reason. Yeah.
34:40>> So you have experience on git right? So
34:44can you tell me what is the difference
34:45between git and github? Git is basically
34:49a distributed version control system
34:52used to track the code changes and
34:55GitHub is a cloud-based platform where
34:58git repositories are hosted and managed.
35:01So yeah.
35:02>> Okay. So can you tell me what are the g
35:05commands you are aware of?
35:06>> Yeah. So there are many commands like uh
35:09we have uh get clone first of all. So uh
35:13whenever we have to clone for from the
35:15remote repository so we use get clone
35:18and then uh uh suppose we make any
35:22changes uh to our uh downloaded
35:25repository then we can say get status.
35:27So it will check it will show whatever
35:30changes we have done and uh then we have
35:33get uh add. So if suppose if you want to
35:36push the file uh like add and push to
35:39repository then we can add that and give
35:42that file name whatever we want to uh we
35:45are planning to push and then we say get
35:48commit minus m so and we can give the
35:51message. So appropriate message we can
35:53give why we are pushing what changes we
35:55have done and all. And then we have git
35:58push. So that we use for for the push.
36:01And then uh uh we also have git log. So
36:04that we use to view uh commit history.
36:07Apart from that we have g branch. So it
36:10will list out all the branches or if we
36:13want to check out some specific branch
36:15so we can just say get check out uh that
36:17branch name. So it will switch to that
36:19specific branch. And uh apart from that
36:23we have get status. So suppose uh we are
36:27using uh any changes we have done to uh
36:32some specific branch and uh we don't
36:35want to lose that and we have to make
36:36some changes to different branch. So
36:38till we temporarily save that uh uh
36:41uncommitted changes and uh so that we
36:45stash that and later once we come back
36:47to that branch we can again uh uh revert
36:50it and uh we can uh push that whatever
36:54changes we want. So yeah, so these are
36:56the mostly we use the uh these commands.
36:59Yeah.
37:00>> Okay. Do you know git rebase?
37:02>> Yeah. G rebase is used to move or uh
37:07replay your branch commit on top of
37:10another branch to maintain a clean and
37:12uh linear commit history. So suppose
37:16when we use git rebase. So get takes the
37:20uh commits from our current branch and
37:22applies them again on top of the another
37:24branch.
37:25>> Okay. So can you tell me what is CI/CD?
37:28>> CICD. So yeah, so CI/CD basically stands
37:30for continuous integration and
37:32continuous uh deployment. So it uh
37:35automates the process of building,
37:37testing and deploying applications. So
37:40uh continuous integration means
37:42developers regularly push their code to
37:45a shared repository like GitHub and
37:48whenever code is pushed so the project
37:50is automatically built and unit test are
37:53executed and code quality checks and all
37:56are performed. So if something fails
37:59then the team is uh like immediately
38:01notified so that we can fix it. So
38:03basically this helps to catch uh like
38:05bugs early and avoids uh integration
38:09issues later and the continuous
38:11deployment basically uh after the build
38:14and test are successful. So the
38:17application is automatically deployed to
38:19uh staging or production. So no manual
38:23uh deployment is needed in full
38:26continuous deployment. So in continuous
38:28delivery deployment may require manual
38:31approval. So, so basically this ensures
38:35the faster and reliable release. So,
38:37yeah. So, that is what CI/CD pipeline we
38:40build. Yeah. Okay. And what is the
38:42difference between docker image and
38:44container?
38:45>> Yeah. So, image is a blueprint we can
38:48say. So, uh and container is a running
38:52instance of that image. So, docker image
38:56is read only template and docker
38:58container is a running version of that
39:00image. So for example we have a java
39:03spring boot app package and all. So that
39:05is we can say image and running the
39:07spring boot application like uh that we
39:10do on container.
39:12So yeah
39:13>> and do you know what is blue green
39:15deployment are you aware of it?
39:18>> Yeah. So it is a deployment strategy
39:21with uh two environments. So blue means
39:23current and green means new. So uh blue
39:27like live production environment is
39:29there then we say blue and green like
39:31new version. So once testing is done on
39:34green then traffic is switched off uh
39:36like switched from the blue to green. So
39:39if something fails we switch back
39:41easily. So
39:43basically this reduces the down time. So
39:46yeah, so that's what uh blueg deployment

About this transcript

This page contains the full transcript of 🔔 Java / Full Stack Developer | 2–8 Years Experience | Spring Boot | Microservices | ReactJS | Git by Insights Instructor, generated from the public captions YouTube serves with the video. The transcript has 6,084 words across 882 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.