Вопросы на собеседовании: Java-разработчик

Я бы сначала рассчитал весь process и load-test несколько heap sizes вместо выдачи всех 8 GiB в `-Xmx`.

• Резервируется measured space для metaspace, code cache, thread stacks, direct buffers, native libraries и примерно 10%-15% container headroom.
• Начну около `-Xms4g -Xmx4g`, затем сравню allocation stalls, GC CPU, live-set margin, pause percentiles, RSS и p99 под sustained allocation 1,2 GiB/s.
• Оставлю smallest heap, выполняющий p99 120 мс и throughput без old-generation growth или container memory pressure.

Я бы сначала benchmark ZGC, потому что pause target 10 мс на 32 GiB favore concurrent relocation, сохранив G1 как throughput baseline.

• ZGC обычно держит short pauses на large heaps, но потребляет concurrent CPU и extra memory, поэтому available headroom 25% проверяется.
• G1 может дать лучший throughput, если young и mixed collections остаются ниже 10 мс при measured live set и allocation rate.
• Решение использует p99 и p99.9 pauses, application throughput, GC CPU, RSS, allocation stalls и recovery после traffic bursts.

Я бы записал steady workload и unified GC logs до изменения одного flag за раз.

• Собираются allocation rate, live set после full marking, young и mixed pause distributions, remembered-set work, promotion, evacuation failures, concurrent-cycle timing и GC CPU.
• Lower `MaxGCPauseMillis` может уменьшить young collections и повысить frequency, а manual young sizing может конфликтовать с G1 ergonomics.
• Change остаётся только при improvement end-to-end p99, throughput и CPU через warm-up, steady state и old-generation pressure.

Я бы тестировал Generational ZGC, когда большинство objects die young, а non-generational ZGC тратит лишнюю работу на весь allocation stream.

• Supported Java 21 option включается в isolated benchmark с одинаковыми heap, workload, warm-up и container limits.
• Измеряются pause percentiles, allocation stalls, concurrent GC CPU, remembered-set overhead, live-set recovery, throughput и RSS несколько часов.
• Adopt только если workload 3 GiB/s выигрывает CPU или throughput без regression latency или operational supportability.

Я бы держал temporary objects local и nonescaping, чтобы C2 мог scalar-replace их после inlining.

• Return object, store в field, передача opaque code или lost inlining могут заставить allocation escape и остаться в heap.
• JFR или async-profiler allocation profiles проверяют allocations compiled code, а JIT compilation logs объясняют failed inlining или deoptimization.
• JMH benchmark с consumed results и warmed forks должен показать lower allocation и equal behavior до переписывания readable domain code.

Я бы сокращал allocation только в measured hot paths, потому что 900 MiB/s всё равно тратит GC CPU и memory bandwidth при short pauses.

• TLAB делает отдельные allocations cheap, но refills, young-region turnover, survivor copying и promotion потребляют shared resources.
• Profile bytes и objects по allocation site, затем target boxing, temporary collections, string formatting и oversized buffers с clear ownership.
• Change принимается только при improvement CPU, throughput или capacity без unsafe pooling или readability cost выше gain.

Я бы отделил time to reach safepoint от stop-the-world operation 12 мс.

• Threads в native calls, long counted loops или paths с delayed polling могут задержать global synchronization при коротком collector work.
• Safepoint logs, JFR thread states и stack samples находят slow thread и involvement JNI, compiler activity или diagnostic action.
• Fix направлен на blocking native или polling path; collector pause flags не удалят 168 мс достижения safepoint.

Я бы сравнил dominators и GC-root paths в equivalent workload points и связал growth с explicit retention policy.

• Leak обычно растёт через listeners, static collections, thread locals, class loaders или keys, которые должны expire.
• Legitimate cache должна иметь configured maximum, eviction metrics, hit value и retained size, correlated с expected key cardinality.
• MAT histograms и dominator deltas находят owners extra 2,3 GiB, а forced full GC подтверждает только reachability, не usefulness.

Я бы дал каждому deployment один disposable child class loader и удалял strong references при stop plugin.

• Threads, thread locals, JDBC drivers, logging registries, executors, MBeans и static parent caches часто retain old loaders.
• Class-unload и Native Memory Tracking metrics плюс `jcmd VM.classloader_stats` проверяют disappearance loader generations после full marking.
• Churn test должен load и unload значительно больше 400 versions с bounded metaspace до acceptance lifecycle.

Я бы считал 2 GiB measured native budget, а не guaranteed spare memory.

• Учитываются direct buffers, metaspace, JIT code cache, thread stacks, GC structures, JNI libraries, memory mappings и allocator fragmentation.
• Monitor RSS, NMT categories, Netty allocator metrics, thread count и `BufferPoolMXBean`, затем cap direct memory и pools по observed peak.
• Оставляется container headroom для bursts и kernel accounting; если native peak выше budget, heap или concurrency уменьшается до OOM kill.

Я бы использовал bounded direct-buffer pool networking library, если profiling показывает copy или allocation cost, а не custom unbounded pool.

• Direct buffers снижают native I/O copies, но имеют allocation и cleanup costs и потребляют memory outside Java heap.
• Arenas и maximum retained capacity size по concurrency и payload percentiles, oversized buffers не возвращаются common pools.
• Throughput, CPU, RSS, allocator fragmentation, pool hit rate и tail latency сравниваются с heap buffers на 40 000 RPS.

Я бы отделил startup capacity от steady-state и warmed real hot paths до ready replica.

• JFR и compilation logs показывают tiered compilation, code-cache pressure, inlining, uncommon traps и repeatedly deoptimized methods.
• Representative warm-up сохраняет branch и type profiles; synthetic calls с другими receivers могут создать misleading compiled code.
• Capacity planning включает readiness 90 секунд, rollout surge и cold-replica routing, а compiler flags вторичны к unstable profiles.

Я бы проверил, отключил ли larger heap compressed ordinary object pointers или изменил object alignment.

• Compressed oops часто работают ниже JVM-dependent addressable threshold около 32 GiB, уменьшая reference и header width.
• `jcmd VM.info`, startup logs, JOL и class histogram подтверждают pointer mode и actual object layout вместо nominal threshold.
• Сравниваются total RSS, live-set bytes, cache locality, pause behavior и p99; heap 40 GiB может дать меньше effective capacity, чем ожидалось.

Я бы benchmark primitive-oriented layout, потому что 30 млн object headers и references могут доминировать actual price data.

• Records улучшают immutability и API clarity, но остаются heap objects и не удаляют headers или pointer chasing автоматически.
• Parallel primitive arrays или packed off-heap structure улучшают density и locality, но добавляют indexing, lifecycle и safety complexity.
• Выбор делается по measured bytes per entry, scan throughput, update pattern, GC pressure, serialization cost и maintainability.

Я бы continuously записывал low-overhead JFR и trigger async-profiler во reproduced burst для higher-resolution stacks.

• JFR связывает CPU, allocation, locks, threads, GC, safepoints, I/O и application events на одной timeline.
• async-profiler добавляет wall-clock, CPU, allocation и lock flame graphs с sampling без safepoint bias.
• Один 30-second window и request IDs должны связать hot stacks с latency, иначе flame graph оптимизирует unrelated background work.

Я бы published immutable configuration через volatile reference или другой explicit happens-before edge.

• Volatile write reference happens-before later volatile reads, делая все prior constructor writes visible readers.
• Final fields добавляют initialization guarantees, только если `this` не escapes during construction; сами они reference не publish.
• Replacement complete object не позволяет readers увидеть mix old и new values между fields.

Я бы использовал `LongAdder`, когда high write throughput важнее atomic instantaneous total.

• `AtomicLong` выполняет CAS на одной cache line, поэтому retries и coherence traffic резко растут под 32-core contention.
• `LongAdder` распределяет updates по cells и sums при read, меняя extra memory и non-linearizable snapshots на write scalability.
• JMH contention benchmark плюс accuracy contract metric решает, полезен ли gain 8 million per second.

Я бы начал с `synchronized` для simple mutual exclusion и выбрал `ReentrantLock` только ради required capability, proven contention tests.

• `ReentrantLock` добавляет timed и interruptible acquisition, multiple conditions и optional fairness, которая может снизить throughput.
• 40 microseconds на 32 contenders делает lock partitioning или shorter critical sections важнее выбора lock implementation.
• JFR lock events и production-shaped benchmark сравнивают wait time, throughput, p99 и cancellation behavior.

Я бы вынес slow I/O из atomic map computation и хранил short-lived future или promise per key.

• First caller installs `CompletableFuture`, выполняет loading на bounded executor, followers share result без duplicate calls.
• Failures намеренно remove или expire placeholder, чтобы один exceptional future не poisoned key forever.
• Total in-flight loads bounded, измеряются bin contention, duplicate suppression, loader p99, memory и timeout behavior на 5 000 keys per second.

Rough blocking ratio предлагает около 160 running и waiting threads для full CPU utilization, но throughput demand делает downstream capacity real bound.

• Estimate: 16 умножить на 1 плюс 45 делить на 5, получается около 160 threads до scheduling и memory overhead.
• При 2 000 RPS и wait 45 мс Little's Law даёт около 90 concurrent I/O operations, которые должны fit connection pools и downstream limits.
• Load-test queue delay, CPU, thread count, connection use, p99 и rejection, затем bounded queue вместо unlimited work.