JPMorgan Chase

Yes, the argument is any int; by convention 0 means success and non-zero means failure. The operating system keeps only the low 8 bits on Linux and macOS, so System.exit(-1) is seen by the shell as 255.

• System.exit starts the shutdown sequence: registered shutdown hooks run (concurrently, in unspecified order), then the JVM halts. It never returns normally.
• finally blocks and try-with-resources closing on the calling thread are skipped; use hooks or a graceful-shutdown path instead.
• Runtime.halt skips hooks entirely and should be reserved for unrecoverable states.
• In Spring Boot prefer SpringApplication.exit(context, () -> code) so beans are closed before the exit code is returned.

Runtime.getRuntime().addShutdownHook(new Thread(() -> System.out.println("cleanup")));
try { System.exit(-1); } finally { System.out.println("never printed"); }

Prints cleanup and the process exit code is 255.

Group by LTS release: Java 8 brought the functional style, 11 modernised the standard library, 17 added data-modelling features, and 21 added virtual threads and pattern matching for switch.

• Java 8: lambdas, streams, Optional, default and static interface methods, java.time, CompletableFuture.
• 9 to 11: modules, List.of/Map.of, var (10), HttpClient, new String methods (isBlank, strip, lines, repeat), single-file source launch.
• 12 to 17: switch expressions (14), text blocks (15), records and instanceof patterns (16), sealed classes (17), strong encapsulation of JDK internals.
• 18 to 21: virtual threads, record patterns and pattern matching for switch, sequenced collections.
• Backend use: records for DTOs, text blocks for SQL/JSON, sealed types plus pattern switch for exhaustive domain results, virtual threads for blocking I/O services. Spring Boot 3 requires Java 17.

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; }
}

Comparable defines a class's single natural order (compareTo); Comparator is an external, pluggable ordering (Comparator.comparing(...).thenComparing(...)), allowing multiple orders without modifying the class.

More threads than 20 gain nothing, since they wait for connections. Size the worker pool at about 20 (or slightly above with a short connection timeout) and bound the queue. CPU count (8) is irrelevant for IO waits, but too many threads add contention and memory. Verify with load tests and queue-wait metrics.

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();

It declares resources in the try header; each is closed automatically in reverse order of declaration when the block exits, normally or exceptionally. Resources must implement AutoCloseable.

• Closeable extends AutoCloseable; its close() throws IOException and is idempotent by contract.
• Java 9+ allows an effectively final existing variable: try (r) { ... }.
• Null resources are skipped without NPE.

Java 7 allows catch (IOException | SQLException e) to share one handler. The parameter is implicitly final.

• Alternatives cannot be related by subclassing (IOException | FileNotFoundException is a compile error).
• The static type of e is the least upper bound of the alternatives.

HashMap keeps an array of buckets (Node<K,V>[] table). The key's hashCode() is spread, masked to an index, and the entry is stored in that bucket as a linked list (or a red-black tree when large). Lookup compares hash then equals.

• Index = (n - 1) & hash where n is a power of two.
• Spread function: h ^ (h >>> 16) mixes high bits into low bits.
• Default capacity 16, load factor 0.75.
• Allows one null key and many null values; not thread-safe.

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.

A Map has no order of its own. Stream the entries, sort them with Map.Entry.comparingByValue(), and collect into a LinkedHashMap, which preserves insertion order. TreeMap orders by key only, because its comparator receives keys.

Map<String, Integer> scores = Map.of("a", 3, "b", 9, "c", 5);
LinkedHashMap<String, Integer> sorted = scores.entrySet().stream()
    .sorted(Map.Entry.<String, Integer>comparingByValue().reversed())
    .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue,
             (x, y) -> x, LinkedHashMap::new));
System.out.println(sorted); // {b=9, c=5, a=3}

The JVM splits memory into the heap (objects, shared), per-thread stacks, Metaspace (class metadata, native memory), the code cache (JIT output) and other native areas (direct buffers, thread structures, GC data).

• Heap: young generation (Eden + two survivors) and old generation in generational collectors.
• Each thread has a stack of frames holding locals, operand stack and return info; -Xss sets its size.
• Metaspace replaced PermGen in Java 8 and lives in native memory.

-D sets a system property for the application, -X options are non-standard but widely supported JVM settings (-Xms, -Xmx, -Xss), and -XX options are advanced, implementation-specific flags that may change or disappear between releases.

• Boolean -XX flags: -XX:+UseG1GC enables, -XX:-UseG1GC disables. Value flags: -XX:MaxMetaspaceSize=512m.
• Some need unlocking: -XX:+UnlockExperimentalVMOptions or -XX:+UnlockDiagnosticVMOptions.
• Inspect effective values with java -XX:+PrintFlagsFinal -version; in containers prefer -XX:MaxRAMPercentage over a fixed -Xmx.
• Since Java 9 logging uses -Xlog (e.g. -Xlog:gc*) instead of old -XX:+PrintGC flags.

java -Xms512m -Xmx512m -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -Dspring.profiles.active=prod -jar app.jar

Future only supports blocking get(). CompletableFuture is a composable promise: chain stages with thenApply, thenCompose, thenCombine, handle errors with exceptionally/handle, and complete manually with complete.

• supplyAsync/runAsync run on ForkJoinPool.commonPool() by default; pass an Executor for IO-bound work.
• allOf/anyOf coordinate several futures.

Make the constructor private and expose one instance created safely. The common options are eager initialization, double-checked locking with a volatile field, the initialization-on-demand holder, or a single-element enum.

public final class Config {
    private static volatile Config instance;
    private Config() {}
    public static Config get() {
        Config c = instance;
        if (c == null) {
            synchronized (Config.class) {
                c = instance;
                if (c == null) instance = c = new Config();
            }
        }
        return c;
    }
}

• Without volatile, another thread may see a non-null but partially constructed object because of instruction reordering.
• Eager static final initialization is simplest when construction is cheap.

Spring Framework is the core programming model (dependency injection, AOP, transactions, MVC, data access) that you configure yourself. Spring Boot is an opinionated layer on top that removes the configuration: starters, auto-configuration, an embedded server and production tooling.

• Starters bundle compatible dependencies (spring-boot-starter-web), with versions managed by the parent/BOM.
• Auto-configuration registers beans conditionally (@ConditionalOnClass, @ConditionalOnMissingBean) based on the classpath and properties; your own beans back it off.
• Embedded Tomcat/Jetty/Netty produces a runnable fat jar instead of a WAR deployed to an external server.
• Actuator, externalized configuration, profiles and graceful shutdown are Boot features.
• Boot 3 builds on Spring 6: Java 17 minimum and the jakarta.* namespace.

Use RestClient (Spring 6.1 / Boot 3.2+) for blocking calls in new code; RestTemplate still works but is in maintenance mode, and WebClient is for reactive or non-blocking composition.

RestClient client = RestClient.builder().baseUrl("https://api.example.com").build();
User u = client.get().uri("/users/{id}", 42).retrieve().body(User.class);

User legacy = new RestTemplate().getForObject("https://api.example.com/users/{id}", User.class, 42);

• 4xx/5xx responses raise HttpClientErrorException / HttpServerErrorException unless you handle status explicitly via onStatus.
• Neither client sets sensible timeouts for you; configure connect and read timeouts on the request factory.
• Inject the auto-configured builder (RestClient.Builder) so metrics, tracing and message converters apply.

Group by the month extracted from the joining date and count rows. Include the year (or use date_trunc) unless you really want all years merged.

-- PostgreSQL
SELECT EXTRACT(MONTH FROM doj) AS month, COUNT(*) AS employees
FROM employee
GROUP BY EXTRACT(MONTH FROM doj)
ORDER BY month;

-- per calendar month
SELECT date_trunc('month', doj) AS month, COUNT(*) FROM employee GROUP BY 1 ORDER BY 1;

MySQL uses MONTH(doj). Months with no joiners are absent from the result; to list them, left join against generate_series (PostgreSQL) or a calendar table.

Order is guaranteed only within a partition. The producer picks the partition by key hash, so all events for a key stay ordered. Within a consumer group, each partition is consumed by exactly one member.

• Max parallelism of a group = number of partitions; extra consumers sit idle.
• Rebalances reassign partitions on member join/leave; cooperative-sticky assignor reduces stop-the-world.
• Offsets committed per group/partition; commit after processing for at-least-once.
• Increasing partition count later changes key-to-partition mapping and breaks per-key ordering for new data.

A @KafkaListener method runs inside a listener container that polls a KafkaConsumer. Each partition of a topic is assigned to exactly one consumer in a group, so messages are load-balanced across the group and ordered per partition.

@KafkaListener(topics = "orders", groupId = "billing", concurrency = "3")
void onOrder(ConsumerRecord<String, String> rec, Acknowledgment ack) {
    process(rec.value());
    ack.acknowledge();            // needs spring.kafka.listener.ack-mode=manual
}

• concurrency above the partition count leaves threads idle.
• Different group ids each receive every message (pub/sub); the same group id shares the load.
• Offsets are committed after processing (manual or batch ack mode) for at-least-once delivery, so handlers must be idempotent.
• Configure DefaultErrorHandler with a backoff and DeadLetterPublishingRecoverer, and wrap deserializers in ErrorHandlingDeserializer so a poison message does not loop forever.

Instances register their address in a registry (or the platform tracks them); callers resolve a logical name to healthy instances.

• Client-side: client queries a registry (Eureka, Consul) and load balances itself (Spring Cloud LoadBalancer).
• Server-side: a router/LB looks up instances (Kubernetes Service + kube-proxy/DNS, AWS ALB).
• Registrations are kept alive with heartbeats/TTL or health checks; stale entries cause failed calls, so combine with retries and outlier ejection.
• On Kubernetes prefer built-in DNS service.namespace.svc over a separate registry.

They trade rollout speed, cost and rollback ease.

• Database changes need expand/contract migrations so old and new versions run together.
• Automate canary analysis (error rate, latency vs baseline) with auto-rollback.

Model ParkingLot with floors of typed spots, issue a Ticket on entry, compute a fee by strategy on exit.

• Requirements: multiple floors, vehicle types (bike, car, truck), spot types, entry/exit gates, hourly pricing, full-lot handling.
• Entities: ParkingLot, Floor, Spot (type, occupied), Vehicle, Ticket, FeeStrategy, SpotAllocationStrategy (nearest, lowest floor).
• Concurrency: two cars must not get the same spot; use an atomic tryOccupy() per spot (CAS) or a lock per floor.
• Extensions: EV charging spots, reservations, payment, display boards (Observer).

class Spot {
    private final AtomicBoolean taken = new AtomicBoolean();
    final SpotType type;
    Spot(SpotType t){ type = t; }
    boolean tryOccupy(){ return taken.compareAndSet(false, true); }
    void free(){ taken.set(false); }
}
class ParkingLot {
    Optional<Ticket> park(Vehicle v, Instant now) {
        for (Floor f : floors)
            for (Spot s : f.spotsFor(v.type()))
                if (s.tryOccupy()) return Optional.of(new Ticket(UUID.randomUUID(), v, s, now));
        return Optional.empty();
    }
}

• Fee: FeeStrategy.compute(Duration) with hourly slabs; pick via vehicle type.
• Keep free spots in a queue per type for O(1) allocation instead of scanning.

Partition keys across nodes with consistent hashing (virtual nodes), replicate for availability, evict with LRU/LFU, and let clients or a proxy route requests.

• Requirements: sub-ms get/put, horizontal scale, high availability, TTLs, eviction, optional persistence.
• Estimates: 1M ops/s, 1 TB data; with 64 GB per node, ~20 nodes (plus replicas).
• API: GET key, SET key value ttl, DEL key, INCR.
• Data model: in-memory hash table per node, LRU/LFU lists, slot or hash-ring mapping stored in a config service.

Client lib / Proxy -> Hash Ring (vnodes) -> Node A (primary) -> replica A'
                                         -> Node B ...      ; Config/Gossip for membership

• Routing: consistent hashing minimises key movement on node add/remove (about K/N keys); Redis Cluster uses 16384 hash slots instead.
• Replication: async primary-replica for speed (can lose last writes); failover through sentinel/gossip.
• Hot keys: replicate hot keys or add a local L1 cache; stampede: single-flight loading and TTL jitter.
• Patterns: cache-aside (default), write-through, write-behind; invalidation is the hard part.
• Failure modes: node loss (replica promoted, rewarm), network partition (split brain, so require quorum), thundering herd on mass expiry.

Order instructions from least to most frequently changing, keep the image small, run as non-root and pin versions.

• Copy dependency descriptors first, resolve dependencies, then copy source, so dependency layers stay cached.
• Use a .dockerignore (target/, .git, *.md, IDE files) to shrink build context and avoid cache busting.
• Pin base images by version (ideally digest), not latest.
• Combine related RUN commands, clean package caches in the same layer.
• Use exec-form ENTRYPOINT, a non-root USER, and HEALTHCHECK/probes.
• Never bake secrets into layers (ARG/ENV values are visible in docker history); use BuildKit --mount=type=secret.