In theory everyone knows Hash Map is not Thread Safe and it shouldn’t be used in multi Threaded applications. But still people come out with their own theories that they can use HashMap in their context. Some say they are just reading the data and map is not written to a lot. Unfortunately none of these explanations holds good when one lands up in a synchronization issue. Normally most of the guys do not understand fundamentals around Java Memory Model and Concurrency .One cannot blame them for not knowing their fundamentals as its hard for people to visualize concurrent executions since from college days we are used to sequential executions of program. Continue reading »
May 25
Java supports two intrinsic concurrency mechanisms “synchronized” and “volatile”. We tend to use synchronized or its newer avatar “locks” from java.util.concurrent most of the times without even checking if volatile or some other option could have been a fit. A careful analysis from concurrency perspective could yield a much smarter and performant solution in many of these scenarios. This analysis would need a good understanding of the properties of each of this mechanism, some of the guarantees that they hold and how it impacts a typical program.
This article takes a look from a Java perspective at some of these semantics and guarantees and does a comparison between synchronized and volatile on some of these parameters. I am also going to go over usages of volatile to build highly performant concurrent programs. Continue reading »
Apr 07
Persistence in enterprise solutions is not only about CRUD operations, but handling concurrency. Concurrency is handled mostly by locks at the database levels. These locks are configured at the dataobject level and cannot be easily controlled from the flow. The only way of controlling it based on the flow is a programmatic approach to it (via JPA locking api or equivalents). Most of the concurrency issues are discovered only in the later stages of development or at times only after the application goes live, a code change at these points is very difficult. Continue reading »
Apr 06
When it comes to Java Concurrency no body[except Doug Lea] is sure of correctness of the code. The major problem faced by developers is debugging concurrent bugs. They are not reproducible easily and not debuggable by Remote Java Debug as that can effect the behavior of concurrent program.
In this article I am going to talk about a concurrency issue I faced in Spring. I will run through the steps I used for analyzing it. The conclusion would talk about a thumb rule that we may consider while refactoring concurrent code.
Issue: While using Spring as a bean container in heavy load I was getting some beans which were not initialized completely. Continue reading »
Recent Comments