Understanding Concurrency, Synchronization, and Locking Mechanisms in Java and Hibernate

When a website receives massive traffic, developers must address concurrency issues; this article first clarifies the difference between synchronous (blocking) and asynchronous (non‑blocking) execution, using simple analogies like eating and talking versus eating while listening to music.

It then introduces database phenomena such as dirty data (reading uncommitted changes) and non‑repeatable reads (different values in the same transaction), explaining why they matter in concurrent environments.

Locking mechanisms are discussed on two levels: code‑level locks (e.g., Java synchronized) and database‑level locks (pessimistic and optimistic). For pessimistic locking, a typical SQL statement is shown: select * from account where name="Erica" for update Hibernate can apply this lock via:

String hqlStr = "from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user", LockMode.UPGRADE);
List userList = query.list();

Hibernate lock modes are listed (NONE, WRITE, READ, UPGRADE, UPGRADE_NOWAIT) and how they map to database lock behavior.

Configuration files ( hibernate.cfg.xml) and mapping files ( User.hbm.xml) are provided, showing the optimistic-lock="version" attribute and a version column used for optimistic locking.

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="com.xiaohao.test">
  <class name="User" table="user" optimistic-lock="version">
    <id name="id">
      <generator class="native" />
    </id>
    <!-- version must follow id -->
    <version column="version" name="version" />
    <property name="userName"/>
    <property name="password"/>
  </class>
</hibernate-mapping>

Two test classes ( UserTest.java and UserTest2.java) demonstrate optimistic‑lock conflicts, resulting in StaleObjectStateException when concurrent updates violate version checks.

Case studies illustrate how to handle high‑concurrency scenarios such as ticket booking, stock trading, and large‑scale user tables, recommending strategies like database sharding, read/write splitting, and caching (both application‑level HashMaps and external caches like Memcached).

Performance‑enhancing techniques are summarized: increase network bandwidth, use load balancers (NGINX, Apache), optimize SQL and add indexes, employ caching, generate static pages, and scale out with server clusters.

The article also covers static page generation, URL rewriting, servlet configuration, and the importance of code optimization (avoiding unnecessary object creation, using StringBuilder, preferring ArrayList over Vector, etc.).

Finally, practical solutions for generating unique IDs under high concurrency are offered, including third‑party services, Redis‑based generators, batch‑increment updates, and thread‑pool designs to avoid synchronized bottlenecks.