orElse(value) evaluates its argument unconditionally, even when the Optional is non-empty. That is fine for a literal or cached value but wasteful when the fallback requires a network call or heavy computation. orElseGet(Supplier) is lazy: it only invokes the supplier when the Optional is actually empty. Always prefer orElseGet when the default has any cost, and reserve orElse for cheap constants like "" or 0.

orElseThrow is for the happy-path contract: "this Optional must be present, otherwise the program is in an invalid state". The supplier form lets you craft a meaningful exception with context. Java 10 added a no-arg orElseThrow() that throws NoSuchElementException with a generic message, but the supplier form is almost always preferable because it carries the failing key or id. Use this in service layers where missing data signals a bug rather than a normal branch.

map transforms the value when present and skips when empty; flatMap is the same but for transformations that already return an Optional (so you do not end up with Optional<Optional<X>>). Chaining these is the null-safe equivalent of ?. in Kotlin or ?. in JavaScript. The whole pipeline collapses to "unknown" cleanly whenever any link is empty: no NPE, no nested null checks, no early returns. This is the pattern that justifies introducing Optional to a codebase in the first place.