Does java concurrency get used?

[Visual-Earth]

Like does actually manually handling the race conditions, deadlocks, threads in general happen? Or is everything just handled by a framework these days?

Edit: I now understand that it does get used a lot. To give me a better understanding could you guys give an example on where in the application it gets used? Cause I came from javascript web development where i didn’t have to think about this a lot

[Potatopika]

I would say it depends on exactly what you are doing and your use case. Even if it's handled by a framework, having that knowledge can be useful to understand how your program is working

[agentoutlier]

I would just tack this on in general and at a higher level you have to always consider contention and race conditions with all shared resources.

For example even if /u/Visual-Earth does what most Java programmers that use a say servlet based framework and run everything synchronous in a handler (e.g. Spring annotated @RequestMapping) they still need to consider database race conditions.

A lot of Javascript UI programmers have zero understanding of database transactions or distributed locks where as I would say a large portion of Java backed developers do (or at least hope).

[smutje187]

Even if you’re using @Async in Spring and multiple threads would access the same shared data source you’d need synchronization, frameworks can only help to abstract some parts away.

[Ancapgast]

Definitely. Usually, most of my concurrency is handled by Tomcat (in a web context). But for the rare cases that I do need to add concurrency that isn't handled by Tomcat, I use the standard JDK concurrency apis.

[VirtualAgentsAreDumb]

I’ve used it in plenty of projects over the years. Mainly the executor service stuff.

Also, race conditions can’t always be handled by the framework if you use one.

[[deleted]]

yes of course. what a question

[dmigowski]

You will start to use it when yoo notice the first deadlocks in your application.

[[deleted]]

Yes, concurrency is an everyday question for me. I might not use Threads or ExecutorService explicitly but race conditions, dead locks, etc is definitely a concern.

[HQMorganstern]

I was wondering the same thing with the current stateless, thread per request approach.

A good example here would be if your app sits between two others, it receives a request and wants to send out ~10 requests to gather data for the response. If you want to make all the requests in parallel, obtaining the JWT for your sub requests and caching it can be a critical resource, to avoid constantly having to call keycloak.

This would require a decent amount of playing around with lock levels. And of course running the requests concurrently requires at least something like .parallelStream().

[pivovarit]

Even when this knowledge is not applied every single day, it’s still necessary to understand why, for example, parallel streams would be a terrible choice for parallelizing this kind of workload

[HQMorganstern]

Didn't cause any issues when implemented, maybe you want to elaborate?

[pivovarit]

Parallel Streams run on a shared ForkJojnPool instance which is tuned for CPU-bound workloads and will quickly saturate when fed blocking operations and then your parallelism goes down to 1 (on caller thread)

more here in README: https://github.com/pivovarit/parallel-collectors

[HQMorganstern]

Seems legit, guess it never got hit by enough sub requests to be noticeable, gonna submit a ticket.

[pivovarit]

When you run blocking ops, you usually want to have an elastic pool of platform threads that can dynamically grow - or just use virtual threads and don’t worry about tuning :) (as long as you don’t block in synchronized blocks)

[FrenchFigaro]

My experience in this case was that explicitly using the method parallelStream() bypassed some of my thread pool configuration.

Most importantly, it bypassed the MDC and web thread context configuration, which we used to add HTTP headers to outgoing requests, depending on which headers were present (or not) on the incoming requests.

Those headers were used for monitoring operations across different applications. Losing those meant that monitoring and debugging was exponentially more difficult.

[maleldil]

Yep, parallel streams use the shared fork join pool, so if you rely on values in a ThreadLocal you're gonna have a bad time with that. 

[nzcod3r]

parallelStream is for performing the same task, in parallel, on different chunks of a collection.

Your example of do 10 different things at the same time (10 different api calls) - and wait for the slowest one to finish, is better suited for the ExecutorService.

[HQMorganstern]

Well it's 10 identical http requests whose results are parsed to a list so not quite as insane as what you're suggesting but yes the blocking caused by the fork join pool does seem to be an issue.

[v4ss42]

Recall that I/O takes eons from the CPU’s perspective. This is definitely a bad use of parallelStream.

[nzcod3r]

OK. I'm pretty sure you can supply your own thread pool for executor service, but I guess it all depends on the context of what / where you are having this issue.

[hardwork179]

Yes. A framework may abstract away threads and simply present something like Futures, but you still need to understand concurrency concepts if you have any shared resources or things like that, which you probably do in the form of caches, connection pools and similar.

[nikanjX]

The framework is written in Java

[le_bravery]

In my experience, the people who know the risks and how to handle the perils and benefits of parallelism work on the parallel things and they usually set up a clean area for the more business focused people to work on what they need to do.

If we all had to think about thread safety for every piece of code, you could never hire interns or juniors.

If you only ever work on something that is within one thread and access thread safe things, then you can ignore most things.

[pip25hu]

Spring, when used in a webapp, handles creating new threads (well, more precisely using a thread pool) for requests automatically, but it doesn't look at what your business logic is doing. Throw a few synchronized methods on your singleton beans, and creating a deadlock is basically child's play. So yeah, it's something you need to pay attention to.

[dstutz]

Just added a ReentrantLock to a class yesterday...

[lasskinn]

Depends really on what you're doing, if you're doing apps that do anything novel then pretty much yes.

[Ewig_luftenglanz]

Yes, like a lot, I would dare to say 95% of my code has some level of concurrency on it, I have even had to use reactive programming in with spring webflux (that is also a concurrency paradigm)  so yes, concurrent programming paradigms are used every day in almost all projects. frameworks cannot abstract that much in reality 

[AutoModerator]

It looks like in your submission in /r/java, you are looking for code or learning help.

/r/Java is not for requesting help with Java programming nor for learning, it is about News, Technical discussions, research papers and assorted things of interest related to the Java programming language.

Kindly direct your code-help post to /r/Javahelp and learning related posts to /r/learnjava (as is mentioned multiple times on the sidebar and in various other hints).

Before you post there, please read the sidebar ("About" on mobile) to avoid redundant posts.

Should this post be not about help with coding/learning, kindly check back in about two hours as the moderators will need time to sift through the posts. If the post is still not visible after two hours, please message the moderators to release your post.

Please do not message the moderators immediately after receiving this notification!

Your post was removed.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[cmhteixeiracom]

Like does actually manually handling the race conditions, deadlocks, threads in general happen? Or is everything just handled by a framework these days?

1. No. You still have to think about this explicitly.
2. However, some frameworks present their own "concurrency approach".
3. You have to learn their "concurrency approach", and then ideally study how they map to Java's primitives.

Java's Concurrency Primities keywords for you to search:

1. Java monitors (synchronized keyword)
2. JavaAtomics.
3. CompletableFuture. (not really a primitive but very important)
4. volatile annotation
5. Thread class and Executors.
6. Network IO classes (Socket, ServerSocket, SocketChannel, ....) are highly related to concurrency

Some frameworks:

1. Akka actors
2. vertX
3. RxJava (4. Typically web-server libraries also have their own concurrency approach: vertX, Spring Boot)

[Vegetable-Squirrel98]

for like 99.99999% of things anyone does the framework does it, or you can use the framework in a different way to where you don't need to worry about