Java · Intermediate interview

Generics are a compile-time feature: the compiler checks types and inserts casts, then erases the type parameters so the bytecode uses raw types (Object or the bound). This means generic type info isn't available at runtime — you can't do new T(), instanceof List<String>, or get the actual type via reflection easily. It's why generics interoperate with legacy code but have these runtime limitations.

A bound constrains a type parameter (<T extends Number>). Wildcards add flexibility: ? extends T is an upper-bounded producer you can read T from but not write to; ? super T is a lower-bounded consumer you can write T into. The PECS rule — Producer Extends, Consumer Super — guides which to use, e.g. copying from a source (extends) to a destination (super).

If two objects are equal by equals(), they must have the same hashCode; unequal objects should ideally have different hashes but aren't required to. If you override equals you must override hashCode consistently, or the object misbehaves in HashMaps/HashSets (lookups fail). Both should be based on the same significant fields, and equal objects should stay equal (immutability helps).

Entries hash to buckets; collisions (same bucket) are chained in a linked list, which converts to a balanced tree when a bucket gets large (8+ in modern JDKs) to keep worst-case lookups O(log n). When the load factor (default 0.75) is exceeded it resizes — doubling capacity and rehashing entries. Good hashCode distribution keeps buckets small and lookups near O(1).

Comparable defines a type's natural ordering via compareTo, implemented by the class itself (one ordering). Comparator is a separate object defining an ordering externally, so you can have many and sort the same type different ways without modifying it. You use Comparable for the default sort order and Comparators for alternative or ad-hoc orderings.

Most collection iterators are fail-fast: if the collection is structurally modified during iteration (other than through the iterator), they throw ConcurrentModificationException to flag a likely bug rather than risk undefined behaviour. To modify while iterating, use the iterator's own remove, collect changes and apply after, or use a concurrent collection. It's a safety mechanism, not a guarantee.

Streams provide a functional, declarative way to process collections — you chain operations like filter, map, and collect instead of writing loops. A stream pipeline has a source, intermediate operations (lazy, returning a stream), and one terminal operation that produces a result or side effect. It makes data transformations concise and enables easy parallelism with parallelStream.

List<String> names = users.stream()
  .filter(u -> u.getAge() >= 18)
  .map(User::getName).toList();

Intermediate operations (filter, map, sorted) are lazy — they build up a pipeline and don't execute until a terminal operation (collect, forEach, reduce, count) is invoked. Laziness lets the stream fuse operations and short-circuit (e.g. findFirst stops early), processing each element through the whole chain once rather than materializing intermediate collections. Without a terminal op, nothing runs.

Optional is a container that may or may not hold a value, designed to make absence explicit and reduce NullPointerExceptions — mainly as a return type for methods that might not find a result. You handle it with map, filter, orElse, or ifPresent rather than get(). It's not meant for fields or method parameters; it's a return-value tool to force callers to consider the empty case.

Creating raw Threads per task is expensive and unbounded — it can exhaust resources under load. An ExecutorService manages a reusable thread pool, queues tasks, bounds concurrency, and returns Futures for results, separating task submission from execution. It's the standard way to run concurrent work, and you size the pool to the workload (CPU- vs I/O-bound).

synchronized provides mutual exclusion (only one thread in the block at a time) and visibility, protecting compound actions on shared state. volatile only guarantees visibility — reads/writes go to main memory so threads see the latest value — but not atomicity for compound operations like i++. Use volatile for a simple flag read by many threads, synchronized (or locks/atomics) when you need atomic multi-step updates.

An immutable object can't change after construction, so it can be shared freely between threads with no synchronization — there's no state to corrupt and no visibility problem. You make a class immutable with final fields, no setters, defensive copies of mutable inputs, and a final class. It's the simplest, safest concurrency strategy and underlies value types like String.