Skip to main content

Concurrency in Java – Series

Concurrency and parallelism features in Java are as old as Java itself. The original creators and specification authors rightly presumed that programmers and future state software designs would need high concurrency capabilities to scale their apps. The Java Memory Model and the JVMs are designed from the ground up to support concurrent programming, with basic concurrency support built in the Java programming language and the Java class libraries. Since version 5.0, the Java platform has also included high-level concurrency APIs to ease the complex semantics of working with and understanding Threading behaviors.

This series outlines the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. The series discusses important principles and provides guidance about designing concurrent applications in Java.

The series is divided into following easy to follow posts: 

Hope you enjoy the series. Happy Coding!! 👍

Comments

Popular posts from this blog

Concurrency in Java – Part 3, State Visibility Guarantees

This post is the part 3 story in the  Concurrency in Java – Series  that touches the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. To see the list of posts in this series, please visit  here . ----------------********---------------- In the previous post , we discussed at length about the object behaviour heuristics. In this installment of the series we shall try to examine the common State Visibility Guarantees that we get from the JVM specification and JVM implementations. Locking idioms not just help us in controlling access around program ‘critical paths’ but also allows us to coordinate access and guarantee consistency and durability of state visibility operations. This is an important consideration that JVM specification offers as a subtle guarantee. Without this guarantee, there would actually be little o...

Concurrency in Java – Part 4, Design Thread Safe Classes and Components

This post is the part 4 story in the  Concurrency in Java – Series  that touches the core concepts of concurrency in Java and provides a balanced view from the JVM memory model specifications as well as from the programmer's perspective. To see the list of posts in this series, please visit  here . ----------------********---------------- In the  previous post , we discussed the two State Visibility Guarantees that Java Memory model offers to its practitioners. In this episode of the Concurrency in Java series we shall have an exhaustive discussion about the various critical guidelines that we need to follow when designing thread safe concurrent Java applications. Design Thread Safe Classes and Components Designing thread-safe classes is not a herculean task but rather a simple 'play by the book' set of rules to be followed and adhered to. This section outlines a set of basic guidelines to foll...

Are we DevOps, or SRE?

SRE Vs. DevOps has been a ranging battle for quite sometime now. Ask any operations or infra team in today's bubbling tech shops and, they will tell you, without a flutter, that they are SRE. Scratch them a bit more and, they will tell you how they follow the SRE principles with stories from their daily grind and link them to Google's SRE handbooks. Then drop the big question, "But isn't the same thing DevOps too?" and see them getting confused and incoherent a bit. Now, if you ask, "Or maybe, yours is more of a hybrid model than pure DevOps/SRE?". Now, you might have turned a few heads and even made some ponder further away. Managing "Operations" as a disciplined practice has always been an arduous task. Many companies today have dedicated operations departments engaged in planning and executions, but more often than not, they fail badly. The tech operations landscape is no different. There are always, generally unsolved questions about how t...