DEV Community: Arash Ariani

The Index Problem: When You Need to Know Where You Are in Your Stream

Arash Ariani — Sat, 06 Sep 2025 20:07:18 +0000

The "Simple" Problem

Let me paint the picture. I've got a stream of customer names, and I want to create a numbered list for a report:

List<String> customers = List.of("John Smith", "Jane Doe", "Bob Johnson");
// I want: ["1. John Smith", "2. Jane Doe", "3. Bob Johnson"]

Seems straightforward, right? Well, not with standard Java Streams.

The Ugly Solutions

Attempt #1: The AtomicInteger Hack

My first instinct was the classic AtomicInteger approach that every Java developer has probably written at least once:

AtomicInteger counter = new AtomicInteger(0);
List<String> numbered = customers.stream()
    .map(name -> (counter.getAndIncrement() + 1) + ". " + name)
    .toList();

It works, but... ugh. Look at that thing! I'm creating an external state just to track where I am in my stream. It's not thread-safe if I want to go parallel, it's ugly, and honestly, it makes me feel dirty every time I write it.
Plus, what if I forget to reset the counter? What if I accidentally use the same counter instance somewhere else? This approach is a bug waiting to happen.

Attempt #2: The IntStream Workaround

Then I remembered the "clever" IntStream approach:

List<String> numbered = IntStream.range(0, customers.size())
    .mapToObj(i -> (i + 1) + ". " + customers.get(i))
    .toList();

This only works if I already have a List (not a Stream), and it completely abandons the stream I was working with. Plus, it requires random access, so goodbye to any lazy evaluation benefits.

Attempt #3: The Custom Collector Nightmare

I won't even show you the custom collector I tried to write. Let's just say it involved way too much mutable state and made me question my life choices.

The "Why Is This So Hard?" Moment

I stepped back and thought: "In Kotlin, this would just be list.withIndex().map { (index, value) -> "${index + 1}. $value" }. Why is Java making this so complicated?"
And that's when it hit me. Java Streams are powerful, but they're missing some of the ergonomic features that other functional programming languages take for granted. The standard library was designed conservatively, which is good for stability, but sometimes frustrating for developer experience.

Real-World Index Problems

This isn't just about numbered lists. Here are real scenarios where I've needed indexed operations:

CSV Processing with Error Reporting

// I need to know which LINE failed parsing
try {
    List<Record> records = csvLines.stream()
        .map(this::parseRecord)  // But which line threw the exception?
        .toList();
} catch (ParseException e) {
    // "Error parsing CSV" - Thanks, super helpful!
}

Batch Processing with Progress

// Processing 10,000 records, want to show progress
largeDataSet.stream()
    .map(this::expensiveOperation)  // How do I show "Processing record 3,247 of 10,000"?
    .toList();

Building a Better Solution: The StreamX Journey

So I decided to solve this correctly. Here's how I approached building withIndex for StreamX, step by step:

Step 1: The Naive First Attempt

My first thought was: "Let me just wrap this in a utility method to hide the ugly AtomicInteger":

public static <T, R> Stream<R> withIndex(Stream<T> stream, BiFunction<T, Integer, R> mapper) {
    AtomicInteger counter = new AtomicInteger(0);
    return stream.map(element -> mapper.apply(element, counter.getAndIncrement()));
}

This cleaned up the calling code, but it still had all the same problems:

External mutable state
Not truly parallel-safe
The AtomicInteger overhead for every element

Step 2: The "What If I Collect First?" Attempt

Then I thought, maybe I should just collect in a list first:

public static <T, R> Stream<R> withIndex(Stream<T> stream, BiFunction<T, Integer, R> mapper) {
    List<T> elements = stream.collect(Collectors.toList());
    return IntStream.range(0, elements.size())
        .mapToObj(i -> mapper.apply(elements.get(i), i));
}

This worked, but it broke the whole point of streams! No more lazy evaluation, everything gets materialized into memory immediately. For a large stream, this could be a performance killer.

Step 3: The "I Need to Think Differently" Moment

I realized I was thinking about this wrong. The problem wasn't with Java Streams themselves - it was that I needed to think at the Spliterator level. Streams are built on Spliterators, and that's where the real magic happens.
What if I could create a Spliterator that automatically tracks indices as it processes elements?

Step 4: Building IndexedValue

First, I needed a clean way to represent an element paired with its index:

public record IndexedValue<T>(T value, int index) {
    @Override
    public String toString() {
        return "IndexedValue{value=" + value + ", index=" + index + "}";
    }
}

Simple, immutable, and tells you exactly what it is. No mystery here.

Step 5: The IndexingSpliterator

This is where it gets interesting. I needed a Spliterator that wraps another Spliterator and adds index tracking:

public class IndexingSpliterator<T> implements Spliterator<IndexedValue<T>> {
    private final Spliterator<T> source;
    private int index = 0;

    public IndexingSpliterator(Spliterator<T> source) {
        this.source = source;
    }

    @Override
    public boolean tryAdvance(Consumer<? super IndexedValue<T>> action) {
        return source.tryAdvance(item -> 
            action.accept(new IndexedValue<>(item, index++)));
    }

    @Override
    public long estimateSize() {
        return source.estimateSize();
    }

    @Override
    public int characteristics() {
        return source.characteristics();
    }

    @Override
    public Spliterator<IndexedValue<T>> trySplit() {
        // For simplicity, we don't support splitting (no parallel processing)
        // A full implementation would need to handle this properly
        return null;
    }
}

The key insight here is tryAdvance() every time the underlying Spliterator produces an element, we wrap it with its index and increment our counter. Clean, simple, and the state is encapsulated within the Spliterator itself.

Step 6: Building zipWithIndex

Now I could create the core operation:

public static <T> Stream<IndexedValue<T>> zipWithIndex(Stream<T> stream) {
    return StreamSupport.stream(
        new IndexingSpliterator<>(stream.spliterator()),
        stream.isParallel()  // Preserve parallel characteristics
    );
}

This gives me a stream where each element is paired with its index. Perfect!

Step 7: The Final withIndex Implementation

And finally, the clean API I originally wanted:

public static <T, R> Stream<R> withIndex(Stream<T> stream, BiFunction<T, Integer, R> mapper) {
    return zipWithIndex(stream)
        .map(indexed -> mapper.apply(indexed.value(), indexed.index()));
}

Now I can write:

List<String> numbered = StreamX.withIndex(customers.stream(),
    (name, index) -> (index + 1) + ". " + name)
    .toList();

Why This Approach Wins

1. No External State

The index tracking is encapsulated within the Spliterator. No shared mutable state, no thread safety concerns.

2. Preserves Stream Characteristics

The operation maintains whether the original stream was parallel, ordered, etc. It's a proper stream citizen.

3. Lazy Evaluation

Elements are only processed when needed. The index calculation happens on demand.

4. Composable

You can chain this with other stream operations naturally:

List<String> result = StreamX.withIndex(customers.stream(),
        (name, index) -> (index + 1) + ". " + name)
    .filter(line -> !line.contains("John"))  // Still a normal stream!
    .map(String::toUpperCase)
    .toList();

5. Familiar API

If you've used Kotlin's withIndex() or Scala's zipWithIndex, this feels completely natural.

Real-World Examples

CSV Processing with Error Lines

List<String> errors = StreamX.withIndex(csvLines.stream(),
    (line, index) -> {
        try {
            parseRecord(line);
            return null;
        } catch (ParseException e) {
            return "Line " + (index + 1) + ": " + e.getMessage();
        }
    })
    .filter(Objects::nonNull)  // Only keep the errors
    .toList();

Progress Tracking

int totalSize = data.size();
List<Result> results = StreamX.withIndex(data.stream(),
    (item, index) -> {
        if (index % 100 == 0) {
            System.out.printf("Processing %d of %d (%.1f%%)%n", 
                index, totalSize, (index * 100.0) / totalSize);
        }
        return processItem(item);
    })
    .toList();

Conditional Processing by Position

List<String> htmlRows = StreamX.withIndex(tableData.stream(),
    (row, index) -> {
        String cssClass = index % 2 == 0 ? "even-row" : "odd-row";
        return String.format("<tr class='%s'>%s</tr>", cssClass, row);
    })
    .toList();

The Lessons Learned

Building this feature taught me a few things:

Sometimes the standard library isn't enough - and that's okay! Java can't include every possible utility operation.
Good APIs hide complexity - The final withIndex method is simple to use, but the underlying implementation requires understanding Spliterators.
Functional programming patterns are worth stealing - When Kotlin, Scala, and Haskell all have similar operations, there's probably a good reason.
Performance matters - The Spliterator approach maintains lazy evaluation and stream characteristics.
Real problems deserve real solutions - This wasn't an academic exercise; it solved actual day-to-day frustrations.

Check out the full code, documentation, and examples here: StreamX

Simplify Your Java Business Code by Flow DSL

Arash Ariani — Sat, 10 May 2025 17:50:54 +0000

Let’s be honest – writing workflows in Java can feel like a never-ending game of try-catch, nested conditions, and tedious state management. If you’ve ever had to handle retries, error recovery, or compensations, you know how quickly things get out of hand.

I got tired of that too. That’s why I built Flow DSL, a tiny library that lets you define workflows in a simple, declarative way. It’s all about focusing on what should happen in each step, not how to handle every little detail. Think of it as a storyboard for your business logic – you map out each step, and Flow DSL handles the rest.

What’s the Big Idea Behind Flow DSL?

Traditional Java workflow code is imperative – you’re telling the JVM exactly how to execute each step, which leads to cluttered, repetitive code.

Flow DSL flips the script. It borrows concepts from functional programming – map(), flatMap(), etc. – so you can focus on defining what needs to happen, step by step. Instead of dealing with nested logic and endless if-else chains, you write a clean, linear flow that’s easy to read and maintain.

Why I Built Flow DSL

Every project I worked on had the same pattern – complex workflows with retries, compensations, and error handling sprinkled all over the place. The code became a mess of nested structures and hard-to-track logic.

I thought, "What if I could just write the flow like a story – this happens, then this, then that – and let a library handle the plumbing?" That’s how Flow DSL was born. It’s all about turning your workflow logic into a series of steps without worrying about implementation details.

How Flow DSL Works – Core Features and Concepts

Let’s dive into the good stuff. Here are some of the key features that make Flow DSL tick:

1. Defining a Simple Flow:

Here’s a basic flow that transforms a string and logs the result:

Flow.of(() -> "Hello")
    .map(str -> str + " World")
    .map(String::toUpperCase)
    .onComplete(result -> log.info("Result: " + result))
    .execute();  // Outputs: HELLO WORLD

No nested structures, no clutter. Just a series of steps.

2. Error Handling with Retry and Compensation:

Let’s say you’re processing a payment and want to handle retries and rollback logic:

Flow.of(() -> paymentService.processPayment(order))
    .withRetry(3)
    .withCompensation(() -> paymentService.rollbackPayment(order))
    .onError(error -> log.error("Payment failed", error))
    .execute();

Three retries and a rollback – all in a few lines of code.

3. Parallel Execution:

Need to run multiple tasks concurrently? Easy:

Flow.parallel(
    () -> inventoryService.checkStock(),
    () -> paymentService.verifyFunds(),
    () -> notificationService.prepareEmail()
)
.withParallelism(3)
.execute();

Flow DSL takes care of concurrency so you can focus on what’s important.

4. Context Propagation:

Share data between steps without manually passing it around:

Flow.of(() -> new Order())
    .map(order -> paymentService.processPayment(order))
    .map(payment -> inventoryService.updateStock(payment.getItems()))
    .onComplete(result -> log.info("Order processed successfully"))
    .execute();

5. Timeouts and Backpressure:

Set execution time limits and manage data throughput without complex threading logic.

6. Monitoring and Metrics:

Track the status and duration of each step, making it easy to spot bottlenecks and optimize flows.

Why Flow DSL?

Declarative API: Less boilerplate, more clarity.

Centralized Error Handling: Manage retries and compensations in a consistent way.

Context Management: Pass data across steps without manual state tracking.

Scalability: Run parallel tasks effortlessly with built-in concurrency management.

Extensibility: Easily add new steps or modify the flow without breaking everything.

How You Can Help Shape Flow DSL

Flow DSL is still a work in progress, and I’d love to get your feedback. Try it out, break it, and let me know what works and what doesn’t. Here’s how you can get involved:

Check Out the Code: GitHub Repo

Explore the Docs: Documentation

Raise Issues: Report bugs, suggest features, or ask questions.

Contribute: Have a feature in mind? Open a PR and let’s build it together.

Let’s Make Flow DSL Better – Together!

Flow DSL started as a simple experiment to make workflow management easier, but with your feedback, it can become a powerful tool for Java developers everywhere. Let me know what you think – I’d love to hear your thoughts and ideas. Let’s make Flow DSL the go-to library for declarative workflow management in Java!

Understanding JPA Pessimistic Locking vs. Serializable Isolation in Transactions

Arash Ariani — Sat, 09 Nov 2024 16:24:51 +0000

Most database applications have to control concurrent access to data in order to prevent issues like data inconsistencies, dirty reads, and phantom reads. The two common ways of achieving data consistency and preventing concurrency issues are JPA Pessimistic Locking and Serializable Isolation Level. Both provide ways to control access to shared data, but they do it differently, and each has different performance and consistency trade-offs. This article explains the differences between these two approaches and when to use which of them.

What is JPA Pessimistic Locking?

In JPA (Java Persistence API), pessimistic locking is used to control access to specific rows in a database when multiple transactions might attempt to modify the same data concurrently. JPA pessimistic locks are scoped at the entity level (the specific rows associated with a JPA entity) and involve explicitly requesting locks within a transaction.

How JPA Pessimistic Locking Works

When using JPA's pessimistic locking with a query, the JPA will translate the locking instruction into database-specific SQL.

Here is how it works:

Lock Modes: JPA provides three pessimistic lock modes:
- PESSIMISTIC_READ: Allows reading data while preventing modifications by other transactions.
- PESSIMISTIC_WRITE: Prevents both read and write by other transactions.
- PESSIMISTIC_FORCE_INCREMENT: Forces an increment on a version column in the entity, effectively treating the entity as updated.
SQL Translation: JPA translates these lock modes into SQL statements, such as SELECT... FOR UPDATE, that are compatible with the underlying database.

Example Using JPA Pessimistic Locking

Here is a sample usage of pessimistic locking at the JPA level in a repository method:

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT e FROM Entity e WHERE e.someCondition = :condition")
List<Entity> findWithPessimisticLock(@Param("condition") String condition);

In that case, PESSIMISTIC_WRITE will lock the rows returned by the query so that no other transactions can modify it before the transaction finishes.

Key Characteristics of JPA Pessimistic Locking

- Scope: It locks the rows that match the query criteria, so nobody else can modify those rows.
- Block: It would block any other transaction requesting a lock on the rows in conflict until this one commits or rolls back.
- Performance: Generally lighter on performance, as it only locks specific rows, but does not guarantee the prevention of phantom reads (new rows being added that match the condition after the query has been executed).

Serializable Isolation Level

Serializable isolation is the strictest isolation level available in databases, ensuring that transactions appear to execute sequentially, with no interference from each other. Serializable isolation prevents all concurrency issues, including dirty reads, non-repeatable reads, and phantom reads.

How Serializable Isolation Works

When a transaction is set to a Serializable isolation level, the database enforces strict ordering among transactions. This prevents other transactions from interacting with rows that might impact the results of the transaction, ensuring strict consistency.

There are two common implementations of Serializable isolation:

- Row-Level Locking: Databases like MySQL and Oracle use row locks, and sometimes additional range or gap locks, to control access to specific rows and ensure no new rows can interfere.
- Multi-Version Concurrency Control (MVCC): Databases like PostgreSQL use snapshots and track version conflicts to provide Serializable behavior without locking rows directly.

Example of Using Serializable Isolation

You can apply the Serializable isolation level at the transaction level in Spring, for example:

@Transactional(isolation = Isolation.SERIALIZABLE)
public List<Entity> findWithSerializableIsolation(String condition) {
    return entityManager.createQuery("SELECT e FROM Entity e WHERE e.someCondition = :condition", Entity.class)
                        .setParameter("condition", condition)
                        .getResultList();
}

In this example, the Isolation.SERIALIZABLE level enforces strict isolation, ensuring the query result is consistent with a fully isolated transaction.

Key Characteristics of Serializable Isolation

- Scope: Locks the rows involved and may apply additional range locks to prevent new rows that could impact the transaction’s result.
- Blocking: Other transactions trying to read or write rows impacted by the current transaction will typically be blocked until the transaction completes.
- Phantom Prevention: Prevents phantom reads by locking ranges, ensuring no other transactions can add rows that would affect the current transaction’s result.

Comparing JPA Pessimistic Locking and Serializable Isolation

Choosing the Right Approach

When deciding between JPA pessimistic locking and Serializable isolation, consider the specific requirements of your application:

Use JPA Pessimistic Locking when:

You need to control concurrent access to specific rows without affecting broader queries.
Performance is a priority, and you want minimal overhead from concurrency control.
Phantom reads are not an issue for your application.

Use Serializable Isolation when:

Strict consistency is required, with no room for concurrency anomalies (including phantom reads).
You can tolerate higher performance costs due to the strict concurrency control.
You are running a critical section of code where any data anomaly could be costly.

Both JPA pessimistic locking and Serializable isolation provide robust ways to manage concurrent access to data, but they serve different needs. Pessimistic locking in JPA gives fine-grained control over specific rows, allowing for better performance but with limited consistency guarantees. In contrast, Serializable isolation enforces strict isolation, treating transactions as if they run sequentially, which provides full consistency but may reduce concurrency.

Handling Asynchronous Execution with Transactions in Spring: A Common Pitfall and How to Solve It

Arash Ariani — Wed, 06 Nov 2024 17:06:58 +0000

In modern Spring applications, it is common to combine asynchronous execution with transactional behavior. However, annotating a method with @Async and @Transactional(propagation = Propagation.REQUIRES_NEW) might result in unexpected behavior because Spring manages asynchronous tasks and transactions.

In this article, we’ll explore the issue in detail and demonstrate a solution to handle both asynchronous execution and transaction management correctly.

The Problem: @Async and @Transactional(propagation = Propagation.REQUIRES_NEW)

Consider the following code snippet:

@Async
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveSomething() {
    // save-point one
    // save-point two
}

At first glance, it might seem that everything is working as expected. However, there are some key problems with this configuration that can lead to unintended behavior.

What Happens Behind the Scenes?

@Async Annotation:

The @Async annotation tells Spring to run the method asynchronously in a separate thread. This means the method will not run in the original thread that called it but will be offloaded to a different thread in a thread pool.
Spring uses proxies to manage asynchronous methods. When you call a method annotated with @Async, Spring delegates the execution to an internal Executor that runs the method in a different thread.

@Transactional(propagation = Propagation.REQUIRES_NEW) Annotation:

The @Transactional(propagation = Propagation.REQUIRES_NEW) annotation ensures that a new transaction is started for the method, regardless of any existing transaction. It suspends any active transaction in the calling thread and begins a new transaction for the method.

Transaction management in Spring is generally thread-bound, meaning that the transaction context is tied to the current thread.

The Conflict

The issue arises because @Async runs the method in a different thread, and Spring’s transaction management relies on the thread to bind the transaction. When the method is executed asynchronously, the transaction context from the calling thread does not propagate to the new thread, which leads to the following problems:

The @Transactional annotation will not create a new transaction in the async thread, and any transactional behavior (like rollbacks, commits, etc.) will not be handled correctly.
The REQUIRES_NEW propagation setting won’t apply because the asynchronous method is running outside the original transaction context.

The Solution: Decoupling Async Execution and Transactions

To solve this problem, you can decouple the asynchronous execution from the transactional logic by handling the transaction in a separate service method. Here’s how you can do it:

Step 1: Create a New Synchronous Service for Transactional Logic
Create a new service that handles the transactional logic. This method will be executed synchronously (without @Async) to ensure that the transaction management works as expected.
Step 2: Call the Synchronous Method Asynchronously
You can then call the synchronous transactional method asynchronously using @Async. This ensures that the transactional logic is handled correctly in the main thread, and the asynchronous behavior is still maintained.

Here’s how the refactored code looks:

@Service
public class MyService {

    private final TransactionalService transactionalService;

    public MyService(TransactionalService transactionalService) {
        this.transactionalService = transactionalService;
    }

    @Async
    public void saveSomethingAsync() {
        transactionalService.saveSomething();  // Call the synchronous transactional method asynchronously
    }
}

@Service
public class TransactionalService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void saveSomething() {
        // save-point one
        // save-point two
    }
}

How does it work?

In the refactored solution, asynchronous execution is achieved by annotating the saveSomethingAsync() method with @Async. This means that when saveSomethingAsync() is called, it will run in a separate thread managed by Spring’s asynchronous task executor. Running this in a different thread allows the main thread to continue its execution without waiting for saveSomethingAsync() to complete. This approach is beneficial for scenarios where you want to offload long-running tasks, improve responsiveness, or handle independent operations concurrently.

For transactional behavior, the saveSomething() method in TransactionalService is annotated with @Transactional(propagation = Propagation.REQUIRES_NEW). This ensures that each call to saveSomething() creates a new transaction independent of any existing transaction in the calling method. The REQUIRES_NEW propagation starts a fresh transaction and suspends any existing one, allowing saveSomething() to operate in an isolated transaction context. This means that even if the original calling method has a transaction, saveSomething() will work within its own separate transaction, enabling controlled commits and rollbacks for just this operation.

By decoupling the asynchronous execution from the transactional logic, we ensure that transaction management works as expected. In this setup, the transaction context remains correctly handled within the saveSomething() method, while the saveSomethingAsync() method continues to execute in a separate thread. This separation of concerns allows both the benefits of asynchronous processing and reliable transaction management, enabling independent and safe data operations even when processing concurrently.

When to Use This Approach?

When Transaction Isolation Is Critical: If you need to ensure that certain operations are carried out in a separate transaction (i.e., REQUIRES_NEW), this approach works well.
Asynchronous Operations: If you have long-running, independent tasks that need to be executed asynchronously but also require their own transaction boundaries.

Alternative: Using a Message Queue for Complete Decoupling

If you need more advanced decoupling or wish to handle retries, error handling, and long-running processes, consider offloading the task to a message queue like Kafka or RabbitMQ. By using a message queue, you can ensure that each task runs in its own context, and the transaction can be managed independently.

Understanding JVM Lock Optimizations

Arash Ariani — Mon, 23 Sep 2024 07:24:45 +0000

Concurrency is very critical to the development of robust, scalable applications that can perform several concurrent operations. However, a price needs to be paid for this in terms of synchronization. It incurs performance costs due to the attendant overheads of acquiring and releasing locks. To alleviate these performance costs, several optimizations have been incorporated into the JVM, in several flavors, such as biased locking, lock elimination, lock coarsening, and the notion of lightweight and heavyweight locks.

In this article, we see these optimizations in greater detail, going over how they improve synchronization in multi-threaded Java applications.

Java Locking Basics

In Java, the synchronization of blocks or methods ensures that only one thread can execute a critical section of code at a time. This matters in particular when considering the sharing of resources within the multithreaded environment. Java implements this by relying on intrinsic locks- or sometimes, they are called monitors associated with objects or classes that help manage access to the threads by using the synchronized blocks.

Although synchronization is a necessity for thread safety, it might be quite expensive when contention is low or completely absent. Which is where JVM optimizations step into the frame. Thus, that reduces the cost of locking and will enhance overall performance.

1. Biased Locking

What is Biased Locking?

Biased locking is an optimization targeted at the reduction of the overhead of lock acquisition. It is optimized to reduce the cost of lock acquisition, which is dominated by a single thread or most largely accessed by a single thread. Such programs often acquire and release locks by the same thread with no contention from other threads. The JVM can recognize this pattern and biases the lock to that particular thread; following lock acquisition comes almost for free.

How Does Biased Locking Work?

If biased locking is enabled, then the first time a thread acquires a lock, it makes that lock biased toward that thread. The identity of the thread is recorded in the header of the lock object, and subsequent lock acquisitions by that thread involve no synchronization whatsoever-they just check if the lock is biased toward the current thread, which is a very fast, non-blocking operation.

If another thread tries to acquire the lock, then bias is canceled and JVM falls back to a standard unbiased locking mechanism. At this stage, it is now a standard lock, and the second thread will have to acquire it through a standard locking process.
Benefits of Biased Locking

Performance: Acquisition of the same thread on a biased lock is almost a free lock acquisition.

Hence, contention handling is not needed because other threads have no chance to be involved in acquiring the lock.

Lower Overhead: The state of the lock need not change or synchronization-related metadata be modified except in the event of contention.

When is Biased Locking Used?

Biased locking is useful in applications where locks are mainly accessed by the same thread, such as single-threaded applications or an application that has low lock contention under multi-threading. It's enabled by default in most JVMs.

How to Disable Biased Locking

Biased locking is enabled by default but can also be disabled with the JVM flag like below:

-XX:-UseBiasedLocking

2. Lock Elimination

What is Lock Elimination?

Lock elimination is a very powerful optimization in which the JVM eliminates some unnecessary synchronization (locks) completely. It will inspect the code for any opportunities during its JIT compilation wherein it finds out that synchronization is not necessary. This usually occurs when the lock has been accessed by just one thread, or the object that the JVM will be used to synchronize doesn't share the same object within different threads. Once the JVM deems that it is no longer required, then it does eliminate the lock.

How Does Lock Elimination Work?

In the escape analysis phase of JIT compilation, JVM checks whether the object is confined to a single thread or is used only in a local context. If synchronization on that object can be removed because an object doesn't escape the scope of the thread that created it, then it will be so.

For example, if an object is created and used entirely within a method (and not shared across threads) the JVM realizes no other thread can possibly access the object, and thus that all synchronization is redundant. In such a case, the JIT compiler simply eliminates the lock altogether.

Zero Locking Overhead: Eliminating unnecessary synchronization will also prevent the JVM from paying the cost of acquiring and releasing locks in the first place.

Higher Throughput: Dead synch can sometimes lead to a higher throughput of the application, especially if the code contains many synchronized blocks.

Take a look at this piece of code:

public void someMethod() {
    StringBuilder sb = new StringBuilder();
    synchronized (sb) {
        sb.append("Hello");
        sb.append("World");
    }
}

In this case, synchronization on sb is not necessary since the StringBuilder is used only within the someMethod and is not shared between other threads. By looking at this, the JVM can perform an escape analysis to remove the lock.

3. Lock Coarsening

What is Lock Coarsening?

Lock coarsening is an optimization wherein the JVM expands the scope of a lock to cover more chunks of code instead of continuously acquiring and releasing the lock in loops or small sections of code.

Lock Coarsening Work

If the JVM finds that a tight loop or multiple adjacent code blocks acquire and release a lock too frequently, it can coarsen the lock by taking the lock outside the loop or across several blocks of code. This makes repeated acquisition and release of the lockless expensive and enables a thread to hold the lock for more iterations.

Code Example: Lock Coarsening

Consider this code snippet:

for (int i = 0; i < 1000; i++) {
    synchronized (lock) {
        // Do something
    }
}

Lock coarsening pushes the lock acquisition outside the loop, so the thread acquires the lock only once:

synchronized (lock) {
  for (int i = 0; i < 1000; i++) {
    // Do something
  }
}

The JVM can dramatically improve performance by avoiding more acquires and releases of the lock.

Lock Coarsening Benefits

Less Freedom of Locking Overheads: Coarsening avoids lock acquisitions and releases, especially in hotspot code, such as loops that have been iterated thousands of times.

Improved Performance:
Locking for a longer period improves performance when compared to the scenario in which, without locking, such a lock would be acquired and released multiple times.

4. Light Weight and Heavy Weight Locks

The JVM uses two different locking techniques based on the degree of contention among the threads. Such techniques include lightweight locks and heavyweight locks.

Light Weight Locking

Lightweight locking takes place in the absence of a contention lock, meaning only one thread is trying to acquire that lock. In such scenarios, the JVM optimizes the acquisition using a CAS operation when trying to acquire the lock, which can happen without heavyweight synchronization.

Heavyweight Locking

In case multiple threads want to obtain the same lock; that is, there is contention, the JVM escalates this to heavyweight locking. This would involve blocking threads at the OS level and managing them using OS-level synchronization primitives. Heavyweight locks are slower because they actually require the OS to perform context switching, as well as to manage threads.

Lock Escalation

If contention arises at a lightweight lock, the JVM may escalate it to a heavyweight lock. Escalation here means switching from the fast, user-level lock to a more expensive, OS-level lock which includes thread blocking.

Benefits of Lightweight Locks

Rapid acquisition of a lock: When there is no contention, lightweight locks are far quicker than heavyweight locks because they avoid OS-level synchronization.

Reduced blocking: With no contentions, threads do not block and increase linearly with lower latency.

Disadvantages of Heavyweight Locks

Performance Overhead: Heavyweight locks incur the cost of thread blocking, context switching, and waking up threads with performance degradation at very high contention regimes.

All these optimizations help the JVM improve performance in multi-threaded applications, so developers can now write safe, concurrent code without sacrificing much in the way of synchronization overhead. Understanding these optimizations can help developers design more efficient systems, especially in cases that have a high-performance penalty for locking.

Optimizing Database Performance with Concatenated Indexes

Arash Ariani — Sat, 23 Dec 2023 19:55:09 +0000

Overview

In the world of database management, the efficiency of queries is paramount. Indexing is a powerful technique to enhance query performance, and one versatile option is the concatenated index. This index type allows for the combination of multiple columns into a single index, providing a unique set of advantages and considerations for database administrators and developers.

Understanding Concatenated Indexes

A concatenated index, also known as a composite or compound index, is created by combining the values of multiple columns into a single index structure. The order in which columns are specified in the index definition is crucial, as it determines how the data is physically organized within the index.

-- Concatenated index on (Column1, Column2)
CREATE INDEX idx_Column1_Column2 ON YourTable (Column1, Column2);

Query Performance Impact

The impact of a concatenated index on query performance is significant and depends on the specific queries executed on the database. Let's explore this impact with a practical example.

Consider a scenario where we have a concatenated index on columns CustomerID and ProductID:

-- With concatenated index on (CustomerID, ProductID)
CREATE INDEX idx_CustomerProduct ON Orders (CustomerID, ProductID);

Now, let's examine a query filtering only on CustomerID:

-- Query with concatenated index
SELECT * FROM Orders
WHERE CustomerID = 123;

While the concatenated index can still be beneficial for this query, it might not be as efficient as a dedicated index on CustomerID alone. The database engine must traverse the index entries for ProductID as well, even though it's not part of the WHERE clause.

Column Order Matters

The order of columns in a concatenated index is crucial to its effectiveness. The leftmost prefix of the index is crucial for optimizing queries. For instance, if we reverse the order of columns in the previous index:

-- Concatenated index on (ProductID, CustomerID)
CREATE INDEX idx_ProductCustomer ON Orders (ProductID, CustomerID);

This new index might not be as efficient for queries filtering only on CustomerID because the leftmost prefix does not match the query condition.

the statement "The leftmost prefix of the index is crucial for optimizing queries" is indeed related to the structure of B-tree indexes commonly used in databases.

A B-tree (Balanced Tree) is a data structure that organizes keys in a sorted order for efficient search, insertion, and deletion operations. In the context of a concatenated index, the B-tree structure is constructed based on the order of columns specified in the index definition.

When a query is executed, the database engine aims to use the index efficiently to locate the desired rows. The leftmost prefix of the index refers to the initial columns specified in the concatenated index. This leftmost portion is crucial because the B-tree structure allows for quick search and retrieval of data based on the sorted order of these leftmost columns.

Consider a concatenated index on columns (A, B, C). The B-tree structure organizes the data first by column A, then by column B, and finally by column C. If you have a query that filters based on A and B (e.g., WHERE A = 1 AND B = 2), the leftmost prefix of the index (A) is used efficiently for locating the rows, benefitting from the sorted order of values in column A. However, if you only filter based on column C, the index might not be as efficient for that specific query.

Optimizing for Query Patterns

When deciding on concatenated indexes, it's essential to analyze the most common query patterns in your application. The order of columns in the index should align with these patterns to maximize efficiency. If queries frequently involve specific combinations of columns, a concatenated index on those columns in the right order can significantly enhance performance.

Considerations and Trade-offs

While concatenated indexes can boost performance for certain queries, they may not be optimal for all scenarios. Considerations should be made based on the overall workload of the database and the variety of queries executed.

A Guide to Sargable Queries

Arash Ariani — Fri, 22 Dec 2023 19:47:45 +0000

Overview

In the vast realm of relational databases, query performance is a critical factor that can make or break the efficiency of applications. One essential concept in the pursuit of optimized queries is "sargability." Sargable, short for "Search ARGument ABLE," refers to the ability of a query to make efficient use of indexes, ultimately leading to faster and more scalable database operations.

Understanding Sargability

Sargability revolves around the idea of crafting queries in a way that allows the database engine to leverage indexes effectively. The key lies in constructing queries that can take advantage of index structures, enabling the database to quickly locate and retrieve relevant data. Let's delve into the characteristics that define sargable queries.

Direct Column References

Sargable queries often involve direct column references in the WHERE clause. When a query directly references a column without applying functions or manipulations, the database engine can efficiently utilize indexes associated with that column. For instance:

SELECT * FROM Employees WHERE Salary > 50000;

In this example, the query is sargable because it directly references the Salary column.

Index-Friendly Functions

While using functions in queries is common, not all functions are index-friendly. Sargable queries use functions that still allow the database engine to take advantage of indexes. Consider the following example:

SELECT * FROM Orders WHERE DATE(OrderDate) = '2023-01-01';

The sargability of this query depends on the database's ability to optimize the use of an index on the OrderDate column despite the presence of the DATE function.

Avoiding Function on Columns

To maintain sargability, it's advisable to avoid applying functions directly to columns in the WHERE clause whenever possible. Instead of using:

SELECT * FROM Customers WHERE UPPER(CustomerName) = 'ABC COMPANY';

Consider:

SELECT * FROM Customers WHERE CustomerName = 'ABC Company';
This adjustment enhances the likelihood of the query being sargable.

Range Queries

Sargable queries often involve range conditions, which can efficiently use indexes. For instance:

SELECT * FROM Products WHERE Price BETWEEN 10 AND 50;

This type of query can leverage an index on the Price column for optimal performance.

Conjunctions of Sargable Expressions

Combining multiple sargable expressions using AND typically results in a sargable query. Consider the following:

SELECT * FROM Employees WHERE Salary > 50000 AND DepartmentID = 3;

This query efficiently uses indexes on both the Salary and DepartmentID columns.

Complex Expressions

Queries with complex expressions that involve multiple operations or calculations may not be sargable. For instance:
SELECT * FROM Sales WHERE Quantity * Price > 1000;

The multiplication of Quantity and Price might prevent efficient index usage.

Using LIKE Pattern

Queries using LIKE patterns with wildcards at the beginning (%prefix) can be non-sargable, as they require scanning the entire column. For example:

SELECT * FROM Customers WHERE CustomerName LIKE '%Corp';

This query might not efficiently use an index on CustomerName.

Conclusion

Sargability is not just a theoretical concept; it directly influences the speed and responsiveness of applications. The practice of using direct column references, employing index-friendly functions, and steering clear of unnecessary manipulations on columns enables databases to harness the power of indexes effectively. This, in turn, translates to faster data retrieval and enhanced overall system performance.