10 Proven Strategies to Supercharge API Performance in Java

1. Background

In legacy projects, long‑running API calls often become the biggest bottleneck, prompting a focused effort on interface performance optimization.

2. Summary of Interface Optimization Solutions

1. Batch Processing

Batch the database operations: instead of inserting records one by one inside a loop, collect them and execute a single batch insert or update, reducing I/O overhead.

// for‑loop single insert
list.stream().forEach(msg -> {
    insert();
});

// batch insert
batchInsert();

2. Asynchronous Processing

Move time‑consuming, non‑critical logic to asynchronous execution to lower perceived API latency. For example, a financial purchase API can handle accounting and file‑writing asynchronously because the result is not required immediately.

Implementation options include thread pools, message queues, or scheduled task frameworks.

3. Space‑for‑Time (Caching)

Cache frequently accessed, rarely changed data (e.g., using R2M, local cache, Memcached, or a simple Map) to avoid repeated database queries or heavy calculations. Be aware of cache consistency challenges.

4. Pre‑Processing (Pre‑Fetching)

Pre‑compute and store results (or cache them) before they are requested, such as calculating annualized returns for financial products in advance, so the API can return the ready‑made value instantly.

5. Pooling

Reuse expensive resources like database connections or threads via connection pools and thread pools, following the principle of pre‑allocation and cyclic reuse.

6. Serial‑to‑Parallel Conversion

When independent tasks have no data dependency, execute them in parallel rather than sequentially to cut total execution time, e.g., fetching account, product, and banner data concurrently for a portfolio page.

7. Indexing

Proper indexing dramatically speeds up data retrieval; the article notes common scenarios where indexes may become ineffective.

8. Avoid Large Transactions

Long‑running transactions hold database connections, causing contention. Example code shows a transactional method inserting multiple tasks; adding non‑DB RPC calls (e.g., push notifications) inside the same transaction can create “big transaction” problems such as deadlocks and timeouts.

@Transactional(value = "taskTransactionManager", propagation = Propagation.REQUIRED, isolation = Isolation.READ_COMMITTED, rollbackFor = {RuntimeException.class, Exception.class})
public BasicResult purchaseRequest(PurchaseRecord record) {
    BasicResult result = new BasicResult();
    // insert account task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_account.type(), TaskEnum.Account_bizType.purchase_request.type()));
    // insert sync task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_sync.type(), TaskEnum.Sync_bizType.purchase.type()));
    // insert file upload task
    taskMapper.insert(ManagerParamUtil.buildTask(record, TaskEnum.Task_type.pension_sync.type(), TaskEnum.Sync_bizType.cert.type()));
    result.setInfo(ResultInfoEnum.SUCCESS);
    return result;
}

Mitigation strategies:

Do not place RPC calls inside transactions.

Keep read‑only queries outside transactions.

Limit the amount of data processed within a transaction.

9. Refactor Program Structure

Repeated iterations can lead to tangled code with redundant queries and object creations. Conduct a systematic refactor: evaluate each code block’s purpose, reorder execution, and eliminate duplication.

10. Deep Pagination Issues

Using LIMIT 100000,200 forces the database to scan over 100,200 rows, which is slow. Replace it with an indexed range query, e.g., WHERE id > 100000 LIMIT 200, leveraging the primary key.

SELECT * FROM purchase_record WHERE productCode = 'PA9044' AND status = 4 AND id > 100000 LIMIT 200;

11. SQL Optimization

General SQL tuning—adding appropriate indexes, avoiding full scans, and optimizing pagination—greatly improves API query performance.

12. Fine‑Grained Locking

Use locks only around truly shared resources. Overly broad locks (e.g., synchronizing an entire method that also touches non‑shared code) degrade concurrency, similar to locking a whole house when only the bathroom needs to be secured.

// Wrong: locks non‑shared code as well
private void wrong() {
    synchronized(this) {
        share();
        notShare();
    }
}

// Correct: lock only shared part
private void right() {
    notShare();
    synchronized(this) {
        share();
    }
}

3. Conclusion

Interface performance problems usually accumulate over multiple development cycles. By adopting higher‑level thinking—designing APIs with performance in mind and applying the above techniques—teams can achieve significant cost and efficiency gains.