Altimetrik

Make the class final (or constructors private), all fields private final, no setters, defensively copy mutable inputs in the constructor and outputs in getters, and don't leak this during construction.

public final class Order {
    private final List<String> items;
    public Order(List<String> items) { this.items = List.copyOf(items); }
    public List<String> items() { return items; }
}

IllegalMonitorStateException. wait/notify must be invoked inside synchronized on the same object. Same result when synchronizing on a different object than the one you call wait on.

The executor tries three things in a fixed order: start a core thread, then enqueue, and only when the queue refuses the task start a non-core thread up to maximumPoolSize; if that also fails the RejectedExecutionHandler runs. With an unbounded queue offer() never refuses, so the pool is stuck at corePoolSize and maximumPoolSize is dead configuration.

1. workers < corePoolSize: spawn a worker for this task, even if other core threads are idle.
2. Otherwise workQueue.offer(task); success means an idle worker will take() it later.
3. Queue full and workers < maximumPoolSize: spawn a non-core worker (reclaimed after keepAliveTime).
4. Otherwise reject: AbortPolicy (throws), CallerRunsPolicy (caller executes, natural backpressure), DiscardPolicy, DiscardOldestPolicy.

ExecutorService pool = new ThreadPoolExecutor(
    5, 50, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(200),            // bounded: max threads become reachable
    new ThreadPoolExecutor.CallerRunsPolicy()); // slows producers instead of dropping

Under a spike with the unbounded queue the symptom is rising latency and heap (queued tasks), not rejected tasks. With a bounded queue the pool reaches 5 + 50 threads only after 200 tasks are queued.

Runnable.run() returns nothing and cannot throw checked exceptions; Callable<V>.call() returns a value and may throw Exception. A Future is the handle you get back from ExecutorService.submit, used to wait for the result, cancel or inspect the task.

• submit(Callable) gives Future<V>; submit(Runnable) gives Future<?> whose get() returns null after completion.
• An exception thrown by the task is captured in the Future and rethrown from get() wrapped in ExecutionException; execute(Runnable) instead lets it reach the thread's uncaught-exception handler.
• A Thread only accepts a Runnable; to run a Callable outside an executor wrap it in a FutureTask (which implements both).

ExecutorService ex = Executors.newSingleThreadExecutor();
Future<Integer> f = ex.submit(() -> { if (true) throw new Exception("boom"); return 1; }); // Callable
try { f.get(); } catch (ExecutionException e) { System.out.println(e.getCause().getMessage()); } // boom
ex.shutdown();

Use Executors.newFixedThreadPool(3), submit the tasks (invokeAll blocks until all complete and returns futures in submission order), read results with get(), and always shutdown() in a finally block.

import java.util.*; import java.util.concurrent.*; import java.util.stream.IntStream;

public class Pool3 {
    public static void main(String[] args) throws Exception {
        ExecutorService pool = Executors.newFixedThreadPool(3);
        try {
            List<Callable<String>> jobs = IntStream.range(0, 9)
                .<Callable<String>>mapToObj(i -> () -> i + " on " + Thread.currentThread().getName())
                .toList();
            for (Future<String> f : pool.invokeAll(jobs)) System.out.println(f.get());
        } finally {
            pool.shutdown();
        }
    }
}

Results print in task order 0..8; thread names are pool-1-thread-1..3 and which thread ran which task varies per run.

execute(Runnable) lets the exception escape to the worker's uncaught handler. submit wraps the task in a FutureTask that captures the exception, surfacing it only when you call get() as ExecutionException.

• Fire-and-forget submit silently loses failures.
• ThreadPoolExecutor replaces a worker that died from execute.
• Override afterExecute or wrap tasks in logging for centralized handling.

HashMap: unordered, O(1), nulls allowed. LinkedHashMap: insertion (or access) order, O(1). TreeMap: sorted by key, O(log n), no null keys with natural ordering. Hashtable: legacy, synchronized on every method, no nulls.

• For thread safety use ConcurrentHashMap, not Hashtable or synchronizedMap for high contention.

Java 7 used 16 lock-striped Segments (each a ReentrantLock over a mini hash table). Java 8+ removed segments: an empty bucket is filled with a lock-free CAS; otherwise it uses synchronized on the bucket's first node. Resizing is cooperative (multiple threads migrate bins), and bins treeify like HashMap.

• Reads are lock-free (volatile fields); size() uses striped CounterCells (like LongAdder), so it is an estimate under concurrency.
• No null keys or values.

It is a static final long that versions the serialized form. On read, the stream's UID must equal the local class's UID or InvalidClassException is thrown.

• If omitted, the JVM computes a hash from class name, interfaces, fields and methods; almost any change (even adding a method) changes it and breaks compatibility. Compilers may also compute it differently.
• Declare it explicitly: private static final long serialVersionUID = 1L;.
• Compatible changes: adding fields, adding classes in the hierarchy. Incompatible: removing a field type change, changing a class from Serializable to Externalizable.

Authentication verifies who you are (credentials, token). Authorization decides what that identity may do (roles, permissions, policies).

• Failures: unauthenticated gives 401; authenticated but denied gives 403.
• Authorization models: RBAC, ABAC, ownership checks on each object.

Use groupingBy with a downstream collector for the per-department results, and distinct().sorted(reverseOrder()).skip(1).findFirst() for the second-highest salary. Interviewers often change the requirement mid-way, so be ready to swap downstream collectors.

import static java.util.stream.Collectors.*;
import java.util.*;

record Emp(String name, String dept, double salary) {}

static void report(List<Emp> emps) {
    Map<String, Optional<Emp>> top = emps.stream()
        .collect(groupingBy(Emp::dept, maxBy(Comparator.comparingDouble(Emp::salary))));
    Optional<Double> second = emps.stream().map(Emp::salary).distinct()
        .sorted(Comparator.reverseOrder()).skip(1).findFirst();
    Map<String, Long> count = emps.stream().collect(groupingBy(Emp::dept, counting()));
    Map<String, Double> avg = emps.stream().collect(groupingBy(Emp::dept, averagingDouble(Emp::salary)));
}

Without distinct(), two people with the top salary make the "second highest" equal the highest.

Constructor-injected cycles fail with BeanCurrentlyInCreationException. Setter/field cycles for singletons used to be resolved through early references (three-level cache), but Spring Boot 2.6+ prohibits circular references by default.

• A cycle signals a design problem; break it by extracting a third component, using events, or @Lazy on one injection point.
• spring.main.allow-circular-references=true re-enables the old behavior; use it only as a stopgap.

Use component scanning for your own classes; use @Bean methods in @Configuration classes for third-party classes or when construction needs logic.

• @Configuration classes are CGLIB-proxied (full mode) so that calling one @Bean method from another returns the same singleton instead of creating a new object.
• @Configuration(proxyBeanMethods = false) (lite mode) skips the proxy for faster startup when no inter-bean method calls exist; Boot's own auto-configurations use it.

For singleton beans with setter/field injection Spring exposes early references via a three-level cache and resolves the cycle. With constructor injection it cannot, and throws BeanCurrentlyInCreationException.

• Since Spring Boot 2.6 circular references are prohibited by default (spring.main.allow-circular-references=false).
• Real fix: redesign (extract a third bean, use events), or break with @Lazy on one injection point.

Both bind into the same Environment; YAML is hierarchical and supports lists and multiple profile documents in one file, properties is flat. If both are in the same location, .properties takes precedence over .yml.

server:
  port: 8080
spring:
  datasource:
    url: jdbc:postgresql://db/app
---
spring:
  config:
    activate:
      on-profile: prod
server:
  port: 80

• YAML forbids tabs; indentation errors silently change structure.
• Unquoted no, off and yes parse as booleans in YAML 1.1, so quote values like country code "NO".
• @PropertySource cannot load YAML; use spring.config.import or @ConfigurationProperties.
• Overrides: command-line args and environment variables beat both files.

Add @EnableScheduling and annotate a bean method with @Scheduled(cron = "..."). Spring cron has six fields starting with seconds. With several instances every instance fires the job, so you need a distributed lock or a single scheduler.

@Component
class NightlyReport {
    @Scheduled(cron = "0 0 2 * * *", zone = "Asia/Kolkata") // sec min hour dom month dow
    void run() { /* generate report */ }
}

• fixedRate measures from start to start, fixedDelay from end to next start.
• The default scheduler has one thread (spring.task.scheduling.pool.size=1), so a long job delays all others.
• For cluster safety use ShedLock (a DB or Redis lock row per job), clustered Quartz, or a Kubernetes CronJob.

Within one advice, the handler with the closest exception type (smallest inheritance distance) wins. Across advice beans, @Order/Ordered decides: the first advice (lowest value) that has a matching handler wins, even if a later advice has a closer match.

• Without @Order, advice order is undefined; always set it when advice classes overlap.
• Controller-local @ExceptionHandler methods take precedence over any advice.
• Use basePackages or annotations on @ControllerAdvice to narrow scope.
• A catch-all @ExceptionHandler(Exception.class) should be in the lowest-precedence advice (@Order(Ordered.LOWEST_PRECEDENCE)).