Performance Optimization

Performance Principles

Optimization Process

1. Write correct, clean code first
2. Measure performance with realistic data and realistic load
3. Identify bottlenecks using a profiler, not intuition
4. Optimize the critical path specifically
5. Measure again to confirm the change actually helped

String Operations

StringBuilder for Concatenation

// BAD — string concatenation in a loop is O(n²): each += allocates
// a brand-new String and copies everything built so far into it
String result = "";
for (String item : items) {
    result += item + ", ";
}

// GOOD — StringBuilder mutates a single buffer — O(n)
StringBuilder sb = new StringBuilder();
for (String item : items) {
    sb.append(item).append(", ");
}
String result = sb.toString();

// BEST for the common case — String.join() or Collectors.joining()
String result = String.join(", ", items);

// A single concatenation is fine — javac compiles it to an efficient
// invokedynamic call (StringConcatFactory) since Java 9, not naive + chaining
String msg = "Hello, " + name + "!";   // OK, not a loop

String Interning

String s1 = "hello";
String s2 = "hello";
s1 == s2;   // true — both point to the same interned literal

String s3 = new String("hello");
s1 == s3;   // false — a genuinely new heap object

Collection Performance

Choosing the Right Collection

// ArrayList: fast random access O(1), slower insert/delete in the middle O(n)
List<Order> orders = new ArrayList<>();

// LinkedList: O(n) random access, O(1) insert/delete at a known node —
// in practice ArrayList usually wins anyway due to CPU cache locality

// HashMap: O(1) average get/put, no ordering guarantee
Map<String, Customer> customersByEmail = new HashMap<>();

// TreeMap: O(log n), but keeps keys sorted — only pay for this if you need the order
Map<String, Customer> sortedCustomers = new TreeMap<>();

Initial Capacity

// BAD — default capacity (10) forces several resize-and-copy operations
// as the list grows to 10,000 elements
List<Order> orders = new ArrayList<>();

// GOOD — pre-size when the final size is known or estimable
List<Order> orders = new ArrayList<>(10_000);

// HashMap: account for load factor (default 0.75) to avoid an early resize
int expectedSize = 1000;
Map<String, Customer> map = new HashMap<>((int) (expectedSize / 0.75) + 1);

Avoid Boxed Primitives in Hot Loops

// BAD — unboxing on every iteration
List<Integer> quantities = new ArrayList<>();
int total = 0;
for (Integer q : quantities) {
    total += q;   // autoboxing/unboxing overhead per element
}

// GOOD — primitive array, no boxing at all
int[] quantities = new int[1000];
int total = 0;
for (int q : quantities) {
    total += q;
}

Stream Performance

// Simple iteration — a plain loop has less overhead than a stream pipeline
for (Customer customer : customers) {
    customer.setActive(true);
}

// Complex transformations — this is where streams genuinely earn their keep
Map<Long, List<Order>> ordersByCustomer = orders.stream()
    .filter(Order::isCompleted)
    .collect(Collectors.groupingBy(Order::getCustomerId));

// Parallel streams — only for genuinely CPU-intensive work on large
// collections; the fork-join overhead isn't worth it otherwise
long total = orders.parallelStream()
    .filter(Order::requiresManualReview)
    .count();

// DON'T parallelize: small collections (< ~10,000 elements), I/O-bound
// operations, or anything with side effects on shared state

// BAD — re-traversing the source stream twice
customers.stream().filter(Customer::isActive).count();
customers.stream().filter(Customer::isActive).map(Customer::getEmail).toList();   // second full traversal

// GOOD — collect once, reuse the materialized list
List<Customer> activeCustomers = customers.stream()
    .filter(Customer::isActive)
    .toList();
long count = activeCustomers.size();
List<String> emails = activeCustomers.stream().map(Customer::getEmail).toList();

Object Creation

// Reuse cached immutable instances where the JDK already provides them
Boolean flag = Boolean.TRUE;              // not `new Boolean(true)` — deprecated and pointless
Integer num = Integer.valueOf(42);      // caches -128..127 automatically

// Create genuinely expensive-to-construct objects once, not per call
private static final DateTimeFormatter ORDER_DATE_FORMAT =
    DateTimeFormatter.ofPattern("yyyy-MM-dd");

public String formatOrderDate(LocalDate date) {
    return date.format(ORDER_DATE_FORMAT);   // reused, never rebuilt
}

// Lazy initialization with double-checked locking — still correct with
// `volatile`, but in a Spring application this is rarely something you
// should hand-write: a @Bean or @Service is already a container-managed
// singleton, with lifecycle handled for you
private volatile ExpensiveParser instance;

public ExpensiveParser getInstance() {
    if (instance == null) {
        synchronized (this) {
            if (instance == null) {
                instance = new ExpensiveParser();
            }
        }
    }
    return instance;
}

Virtual Threads (Java 21+) — the Biggest Throughput Change in Years for I/O-Bound Apps

Most Java web services spend the overwhelming majority of a request's time waiting — on a database query, a downstream HTTP call, a payment gateway. Traditional platform threads make that waiting expensive: each platform thread reserves roughly 1MB of stack and maps directly to an OS thread, so a bounded thread pool (Tomcat's default of ~200) becomes the hard ceiling on how many concurrent requests a service can actually be waiting on at once, regardless of how idle the CPU actually is.

// BEFORE — a platform-thread-per-request model: 200 threads waiting on
// a slow payment gateway means request #201 queues, even though every
// CPU core is sitting idle
@GetMapping("/orders/{id}/payment-status")
public PaymentStatus checkStatus(@PathVariable Long id) {
    return paymentGatewayClient.checkStatus(id);   // blocks the platform thread for the full round-trip
}

Virtual threads are JVM-managed, not OS-managed — millions can exist simultaneously because they're cheap (kilobytes, not megabytes) and only occupy an actual OS ("carrier") thread while genuinely running CPU instructions. The moment a virtual thread blocks on I/O, the JVM unmounts it from its carrier thread entirely, freeing that carrier to run a different virtual thread — the blocking code you already wrote (no reactive rewrite needed) now scales to a completely different order of concurrent, waiting requests.

# application.properties — Spring Boot 3.2+, one line switches Tomcat's
# request-handling threads to virtual threads
spring.threads.virtual.enabled=true

// Using virtual threads directly, outside a web container
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Future<PaymentStatus>> results = orderIds.stream()
        .map(id -> executor.submit(() -> paymentGatewayClient.checkStatus(id)))
        .toList();
    // Each submitted task gets its own virtual thread — thousands of
    // concurrent, blocking gateway calls with no reactive code at all
}

Virtual threads help I/O-bound throughput specifically — they do nothing for CPU-bound work, which is still limited by actual core count. See Thread Pools & ExecutorService for how platform thread pools are sized and managed, and Application Servers for how this changes container thread configuration.

Database Performance

Connection Pooling — sized correctly, not maximized

@Bean
public HikariDataSource dataSource() {
    HikariConfig config = new HikariConfig();
    config.setMaximumPoolSize(10);
    config.setMinimumIdle(10);      // match maximum — a fixed-size pool avoids pool churn
    config.setConnectionTimeout(30000);
    return new HikariDataSource(config);
}

Batch Operations

// BAD — N individual round-trips
for (Order order : orders) {
    orderRepository.save(order);
}

// GOOD — a single batched call
orderRepository.saveAll(orders);

Fetch Only What You Need

// BAD — loads every column of every Order just to read the total
List<BigDecimal> totals = orderRepository.findAll().stream()
    .map(Order::getTotal)
    .toList();

// GOOD — a projection fetches only the column actually needed
@Query("SELECT o.total FROM Order o")
List<BigDecimal> findAllTotals();

// Pagination for anything that could grow unbounded
Page<Order> page = orderRepository.findAll(PageRequest.of(0, 20));

Caching

@Service
public class ProductService {

    @Cacheable("products")
    public Product findById(Long id) {
        return productRepository.findById(id).orElseThrow();
    }

    @CacheEvict(value = "products", key = "#product.id")
    public Product update(Product product) {
        return productRepository.save(product);
    }
}

// In-memory memoization for values not backed by a full cache provider
private final Map<String, BigDecimal> taxRateCache = new ConcurrentHashMap<>();

public BigDecimal getTaxRate(String region) {
    return taxRateCache.computeIfAbsent(region, this::lookupTaxRate);
}

Profiling Tools

JMH Benchmark Example

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Thread)
public class StringConcatBenchmark {

    private List<String> items;

    @Setup
    public void setup() {
        items = IntStream.range(0, 100).mapToObj(String::valueOf).toList();
    }

    @Benchmark
    public String stringConcat() {
        String result = "";
        for (String item : items) { result += item; }
        return result;
    }

    @Benchmark
    public String stringBuilder() {
        StringBuilder sb = new StringBuilder();
        for (String item : items) { sb.append(item); }
        return sb.toString();
    }
}

JMH's default warm-up iterations exist because the JIT compiler doesn't optimize code immediately — early calls run interpreted or under a cheap tier-1 compilation, and only "hot" code gets the fully optimized tier-4 (C2) compilation. Benchmarking without a warm-up phase measures the JIT compiler's warm-up cost, not the code's actual steady-state performance.

Best Practices and Common Pitfalls

Interview Questions