Preparación de entrevistas: el módulo que convierte el estudio en oferta

Preséntate a mid alto o senior bajo y deja que el proceso te calibre; no te autoexcluyas de una oferta que dice «5+ años», porque ese número casi siempre es un deseo del hiring manager y no un requisito. Lo que sí tienes que hacer es traer pruebas del comportamiento senior, no de la antigüedad: una decisión de diseño que tomaste y defendiste, un incidente que gestionaste, alguien a quien mentorizaste, una migración que planificaste en fases.

La conversación honesta que funciona en la primera llamada es: «tengo cuatro años, pero he sido el responsable técnico de dos servicios en producción con guardias. Me presento a senior; si al conocerme encajo mejor en mid, prefiero que me lo digáis y hablamos de qué me falta.» Eso demuestra criterio y no cierra puertas.

Trampa: si te vendes como senior y no sabes decir qué pasa cuando tu servicio recibe el doble de tráfico, o no has visto nunca un despliegue romperse, la repregunta te va a dejar sin argumentos. Es mejor entrar como mid con una revisión a seis meses que entrar como senior y no llegar a la expectativa.

Sí, si cumples el núcleo. Las ofertas se escriben sumando los deseos de tres personas y casi nadie las cumple al cien por cien; el filtro real son dos o tres puntos, y el resto es lista de la compra. Mi regla: si cumples el lenguaje principal, el framework principal y el nivel de seniority, aplica aunque falten Kafka, Kubernetes o el sector.

Lo que no funciona es ignorar el hueco. Nómbralo tú, con un plan: «no he trabajado con Kafka en producción, he montado un consumidor con Spring Kafka en un proyecto propio y entiendo particiones, grupos y entrega al menos una vez; me pondría al día en semanas, no en meses». Eso convierte una carencia en una demostración de honestidad y de capacidad de aprendizaje.

Trampa: no digas «aprendo rápido» sin evidencia. Es la frase más vacía del mercado. Da un ejemplo concreto de algo que aprendiste en poco tiempo, con qué material y qué entregaste con ello.

Con un CV decente y un stack demandado como Java y Spring, la aritmética típica en España es: de 40 a 60 candidaturas dan 8 a 15 primeras llamadas, 4 a 8 procesos técnicos y 1 a 3 ofertas. Si estás muy por debajo de esos números, el diagnóstico se hace por etapas: si no te llaman, el problema está en el CV, en el encaje o en el canal; si te llaman y caes en la técnica, es profundidad o comunicación; si llegas al final y no cierras, suele ser expectativa salarial o la parte humana.

Dos ajustes que cambian mucho la tasa: candidaturas dirigidas (una línea que demuestre que has mirado su producto) en lugar de masivas, y usar la puerta lateral —alguien de dentro, la comunidad, el propio equipo en LinkedIn— en las diez empresas que más te importan.

Por este orden, porque es el orden de coste creciente y de impacto decreciente: (1) el CV —una página, logros con números, palabras clave del puesto—; (2) el canal —si solo aplicas por portales masivos, cambia a ofertas directas de la empresa y a contacto humano—; (3) el nivel y el rango al que te presentas, porque presentarse a senior con perfil de mid produce silencio; (4) la primera llamada, grabándote para ver si tu respuesta a «háblame de ti» es un relato o un paseo por tu CV; (5) la profundidad técnica, que es lo que la mayoría revisa primero y casi nunca es el cuello de botella real.

Y algo poco intuitivo: pide feedback explícitamente a los que te descartan, aunque solo responda uno de cada cinco. Una sola frase honesta de un entrevistador ahorra semanas de suposiciones.

Es un problema de memoria de trabajo, no de conocimiento, y se ataca de tres formas. La primera: gana tiempo en voz alta con una frase de arranque que sea siempre la misma —«vale, déjame ordenarlo: hay dos partes en esto»—; suena reflexivo y te da cinco segundos reales para recuperar el hilo. La segunda: empieza por el ejemplo concreto en lugar de por la definición. Recordar «el bug del HashSet que tuvimos por hacer mutable la clave» es mucho más fácil que recitar el contrato de hashCode, y la definición sale sola tirando del ejemplo.

La tercera es preventiva: práctica de recuperación, no de relectura. Leer las respuestas de este módulo diez veces no entrena la recuperación; responder en voz alta con el desplegable cerrado, sí. Es el mismo principio que hace que las tarjetas de repaso funcionen y el subrayado no.

Trampa: si te quedas de verdad en blanco, dilo: «se me ha ido, dame un segundo». Es infinitamente mejor que un silencio largo o que empezar a divagar. Nadie descarta a un candidato por un blanco de cinco segundos; muchos descartan por dos minutos de relleno sin contenido.

Sí, y es una buena práctica siempre que las uses como índice y no como guion. Lo aceptable: una página con tus seis historias en una línea cada una, tus preguntas para ellos, el nombre de quien te entrevista y los números clave de tu experiencia. Lo que se detecta y queda fatal: leer respuestas técnicas de la pantalla —cambia el ritmo del habla, la mirada se va y las frases se vuelven demasiado perfectas—.

Si consultas algo, dilo con naturalidad: «déjame mirar el número exacto, lo tengo apuntado». Eso no resta nada; al contrario, transmite rigor. Y en un live coding, preguntar «¿puedo consultar la documentación?» casi siempre recibe un sí, porque es lo que harías en el trabajo real.

Prepara el vocabulario técnico y las cinco respuestas de arranque, no la gramática. En la práctica, el 80 % de una entrevista técnica en inglés se juega con doscientas palabras: trade-off, bottleneck, throughput, latency, rollback, staging, deadlock, thread-safe, eventually consistent, idempotent… Escribe tu presentación en inglés y dila veinte veces en voz alta hasta que salga sin pensar. El arranque fluido compra mucha paciencia para el resto.

Durante la entrevista: habla más despacio de lo natural, usa frases cortas y no traduzcas del español (las subordinadas largas es donde te vas a atascar). Si no entiendes algo, pide que lo repitan sin disculparte cinco veces: «sorry, could you rephrase that?». Y avisa al principio si te ayuda: «my English is good enough for technical discussions, but tell me if I go too fast». Nadie penaliza el acento; sí penaliza que asientas a una pregunta que no has entendido y respondas otra cosa.

En una frase, sin dramatismo y con lo que hiciste. «Estuve un año fuera del mercado por [motivo breve]; en ese tiempo hice [algo concreto: cuidar de un familiar, un proyecto propio, formación, recuperarme de una baja] y desde [mes] estoy buscando activamente.» Punto. El error no es el hueco, es tratarlo como un secreto culpable: si tú lo tratas como algo normal, el entrevistador lo trata como algo normal.

Si el hueco fue formativo, ten la prueba: el repositorio, el curso terminado, la certificación. Si fue personal, no tienes ninguna obligación de dar detalles médicos o familiares, y una respuesta corta y tranquila cierra el tema. Lo que sí conviene es que el CV lo muestre con fechas claras en lugar de esconderlo cambiando los meses, porque una incoherencia detectada pesa mucho más que el hueco en sí.

Trampa: «he estado haciendo proyectos personales» sin poder enseñar ninguno es la peor versión de esta respuesta. Si lo dices, ten el enlace preparado.

Entre 45 y 120 segundos para una pregunta conceptual, y hasta tres minutos si te piden contar un caso completo. La referencia práctica: si estás hablando más de dos minutos y el entrevistador no ha intervenido ni una vez, para y pregunta «¿quieres que profundice o paso a lo siguiente?».

El otro extremo también es un problema. Una respuesta de diez segundos —«volatile garantiza visibilidad»— es correcta y no da ninguna señal; el entrevistador tiene que trabajar para sacarte lo que sabes, y eso puntúa mal. Añade siempre el por qué y un ejemplo, aunque no te lo pidan.

Sí, con moderación: una o dos veces en la entrevista, y en las preguntas grandes. Es una señal de orientación al interlocutor y evita el peor escenario, que es responder brillantemente a una pregunta distinta de la que te hicieron. Formulaciones que funcionan: «¿voy por donde te interesa?», «¿quieres que entre en la parte de rendimiento o en la de consistencia?».

Lo que no debes hacer es preguntarlo después de cada respuesta, porque entonces suena a inseguridad y a buscar aprobación. Y no lo uses como sustituto de pensar: si no entendiste la pregunta, pregunta antes de responder, no después.

Pensar en voz alta no es narrar cada tecla, es hacer visibles tus decisiones. Tres cosas y ya está: (1) di qué vas a hacer antes de hacerlo —«voy a empezar por la firma del método y un test con el caso simple»—; (2) nombra las alternativas que descartas y por qué —«podría usar un Set, pero necesito el índice, así que un Map»—; (3) señala los riesgos que ves aunque no los vayas a tratar todavía —«esto explota con entrada nula; lo dejo anotado y lo cubro al final».

Lo que suena mal es el silencio de dos minutos seguido de código perfecto: el entrevistador no puede evaluar lo que no ve, y si no habla contigo no sabe si has entendido el problema o has recordado la solución. Si te bloqueas, verbaliza el bloqueo: «estoy dudando entre dos formas de tratar los duplicados, te cuento las dos».

Trampa: hablar tanto que no escribes código. Alterna: treinta segundos de explicación, un bloque de código, otra vez explicación.

Sí, siempre, y es una de las cosas que mejor puntúan de toda la entrevista. «Antes te he dicho que volatile hacía atómico el incremento y no es así: garantiza visibilidad y ordenación, pero contador++ sigue siendo una carrera; para atomicidad, AtomicInteger.» Eso demuestra tres cosas a la vez: que sigues pensando, que te importa la corrección más que tu imagen, y que eres alguien en cuyas afirmaciones se puede confiar.

La única condición es que sea breve y sin dramatismo. Una frase de corrección y sigues; no un párrafo de disculpas ni una autoflagelación que cambie el tono de la conversación.

Asume que es su estilo o que está teniendo un día malo, y no lo interpretes como una valoración negativa, porque muchas veces no lo es: hay gente que entrevista con cara de póquer a propósito para no sesgar. Lo que sí puedes hacer es tomar tú el control del ritmo: haz respuestas más cortas, pregunta más a menudo «¿quieres que profundice?», y busca su terreno («¿esto os pasa en vuestro sistema?»).

Si de verdad es hostil —interrumpe, ridiculiza, no deja terminar—, mantén el tono profesional hasta el final y apúntalo como dato. Una entrevista es la mejor muestra que vas a tener de cómo se trata a la gente dentro. Nadie te obliga a aceptar una oferta de un sitio donde te trataron mal siendo aún un invitado.

== compara identidad —si las dos referencias apuntan al mismo objeto en memoria— y equals() compara equivalencia lógica según la definición de la clase. En primitivos == compara valores, porque no hay referencias.

Dónde muerde en la práctica: con envoltorios y con cadenas, porque hay caché por medio y el resultado parece aleatorio.

Integer a = 127, b = 127;      // caché de Integer: -128..127
System.out.println(a == b);     // true  ← engañoso
Integer c = 128, d = 128;
System.out.println(c == d);     // false ← el mismo código, otro resultado
System.out.println(c.equals(d));// true  ← lo correcto

String s1 = "hola", s2 = "hola";
System.out.println(s1 == s2);              // true (literales, mismo objeto del pool)
System.out.println(s1 == new String("hola")); // false
System.out.println(s1.equals(new String("hola"))); // true

Regla operativa: para objetos, siempre equals(); el único == legítimo con objetos es contra null, con enum (donde es preferible porque es null-safe y no se puede romper) y cuando de verdad quieres comparar identidad.

Trampa: la repregunta suele ser «¿y con Long en un switch o en un if de un id?». Comparar Long id1 == id2 con identificadores por encima de 127 es un bug clásico que pasa los tests en local (ids pequeños) y falla en producción.

El contrato tiene cinco propiedades para equals —reflexivo, simétrico, transitivo, consistente y false frente a null— y una regla de enlace: si dos objetos son equals, sus hashCode deben ser iguales. La inversa no se exige: dos objetos distintos pueden compartir hash (colisión).

Si rompes la regla de enlace, los objetos se pierden en las colecciones basadas en hash: lo metes en un HashSet, lo buscas y no está, porque se busca en el bucket equivocado.

// El bug: hashCode por defecto (identidad) + equals sobrescrito
class Cliente {
    final String nif;
    Cliente(String nif) { this.nif = nif; }
    @Override public boolean equals(Object o) {
        return o instanceof Cliente c && nif.equals(c.nif);
    }
    // ¡falta hashCode!
}
var set = new HashSet<Cliente>();
set.add(new Cliente("12345678Z"));
set.contains(new Cliente("12345678Z"));  // false → el objeto "desaparece"

La solución en 2026 casi siempre es un record, que los genera correctamente a partir de todos los componentes. Si los escribes a mano, Objects.equals y Objects.hash, y usa solo campos inmutables y significativos del dominio.

Trampa: la repregunta es «¿qué pasa si la clave de un HashMap es mutable y la mutas después de insertarla?». Respuesta: el hash cambia, la entrada se queda en el bucket antiguo y se vuelve inaccesible —ni se encuentra ni se puede borrar— aunque siga ocupando memoria. Es una fuga de memoria silenciosa.

Un objeto inmutable es uno cuyo estado observable no cambia después de construirse. La razón por la que se insiste tanto: es la forma más barata de seguridad entre hilos. Si nada cambia, no hay carreras, no hace falta sincronizar y no hay que razonar sobre visibilidad de memoria.

Receta completa para hacer una clase inmutable:

public final class Dinero {                    // final: nadie hereda y rompe invariantes
    private final BigDecimal importe;           // campos private final
    private final Currency moneda;
    private final List<String> etiquetas;       // ¡cuidado con las colecciones!

    public Dinero(BigDecimal importe, Currency moneda, List<String> etiquetas) {
        if (importe == null || moneda == null) throw new IllegalArgumentException();
        this.importe = importe.setScale(2, RoundingMode.HALF_UP);
        this.moneda = moneda;
        this.etiquetas = List.copyOf(etiquetas);   // copia defensiva al entrar
    }
    public List<String> etiquetas() { return etiquetas; }  // ya es inmutable, no hace falta copiar
    public Dinero mas(Dinero otro) {                        // "mutar" devuelve otro objeto
        exigirMismaMoneda(otro);
        return new Dinero(importe.add(otro.importe), moneda, etiquetas);
    }
}

Los cuatro puntos que hay que nombrar: final en la clase, campos final y privados, copias defensivas de lo mutable (entrada y salida) y ningún setter. Un record te da los tres primeros gratis, pero no hace copia defensiva de una lista mutable que le pases: eso lo tienes que hacer tú en el constructor compacto.

Trampa: «un record es inmutable, ¿no?». Es superficialmente inmutable: sus componentes no se reasignan, pero si un componente es un ArrayList o una entidad JPA, su contenido sí puede cambiar. La inmutabilidad profunda hay que construirla.

Es una zona de la memoria (dentro del heap desde Java 7) donde la JVM guarda una única instancia de cada literal de cadena. Existe porque las cadenas son el objeto más repetido de cualquier programa y son inmutables, así que compartirlas es seguro y ahorra muchísima memoria.

String a = "pedido";                 // va al pool
String b = "pedido";                 // misma instancia del pool → a == b
String c = new String("pedido");     // objeto nuevo en el heap → a != c
String d = c.intern();               // fuerza la búsqueda en el pool → a == d
String e = "pe" + "dido";            // el compilador la resuelve → a == e (constante)
String f = leerDeBd() + "dido";      // en tiempo de ejecución → objeto nuevo

Importa en tres sitios: (1) explica los resultados aparentemente contradictorios de ==; (2) concatenar en un bucle crea un objeto por iteración, y por eso se usa StringBuilder —aunque el compilador ya optimiza la concatenación en una sola expresión—; (3) intern() tiene sentido para deduplicar cadenas muy repetidas leídas de fuera (por ejemplo, códigos de país de un fichero de millones de líneas), pero es fácil de usar mal.

Trampa: nunca uses intern() «por rendimiento» sin medir, y nunca sincronices sobre una cadena internada (synchronized("clave")): el pool es global, así que estarías compartiendo un cerrojo con cualquier otro código de la JVM que use ese literal.

Siempre por valor. Lo que ocurre es que, cuando el argumento es un objeto, el valor que se copia es la referencia. Consecuencia: dentro del método puedes mutar el objeto apuntado, pero no puedes reasignar la variable del llamante.

void mutar(List<String> l) { l.add("x"); }        // el llamante SÍ ve el cambio
void reasignar(List<String> l) { l = new ArrayList<>(); l.add("y"); } // no ve nada

var lista = new ArrayList<String>();
mutar(lista);      // lista = [x]
reasignar(lista);  // lista = [x]  ← sigue igual

void incrementar(int n) { n++; }        // primitivo: copia del valor, no cambia nada
void cambiar(String s) { s = "otro"; }  // String es inmutable: imposible mutarla

La forma de decirlo que suena bien en entrevista: «Java es pass-by-value de referencias; el objeto no se copia, la referencia sí».

Trampa: mucha gente responde «por referencia para objetos, por valor para primitivos». Es la respuesta que el entrevistador está esperando para repreguntar, porque implica que reasignar el parámetro afectaría al llamante, y no es así.

La sobrecarga es polimorfismo estático: varios métodos con el mismo nombre y firma distinta en la misma clase; el compilador elige cuál llamar según los tipos declarados. La sobrescritura es polimorfismo dinámico: una subclase redefine un método heredado con la misma firma, y la JVM elige la implementación en tiempo de ejecución según el tipo real del objeto.

// El clásico que sorprende: se elige por tipo DECLARADO
static void log(Object o) { System.out.println("Object"); }
static void log(String s) { System.out.println("String"); }

Object x = "hola";
log(x);        // imprime "Object", no "String"
log((String) x); // imprime "String"

// Los métodos static se OCULTAN, no se sobrescriben
class Padre { static String quien() { return "padre"; } }
class Hijo extends Padre { static String quien() { return "hijo"; } }
Padre p = new Hijo();
// p.quien() → "padre" (se resuelve por el tipo declarado)

Trampa: te van a preguntar por qué usar @Override. No cambia el comportamiento, pero hace que el compilador falle si crees que estás sobrescribiendo y en realidad estás sobrecargando —el caso típico es equals(Cliente c) en vez de equals(Object o)—, que es uno de los bugs más difíciles de ver a ojo.

Por defecto, interfaz. Una interfaz define un contrato o una capacidad y permite herencia múltiple de tipos; una clase abstracta define una implementación parcial con estado compartido, y consume la única bala de la herencia simple. Desde Java 8 las interfaces tienen métodos default y static, y desde Java 9 private, así que la vieja distinción «las interfaces no tienen código» ya no aplica.

En Spring, además, hay un motivo pragmático: los puertos de la arquitectura hexagonal son interfaces porque permiten cambiar el adaptador y probar con dobles sin tocar el dominio. Pero ojo, la interfaz «con una sola implementación y el mismo nombre más Impl» es ceremonia sin valor: úsala cuando exista un motivo (varias implementaciones, un límite de arquitectura, o un test que la necesita).

Trampa: «¿y el problema del diamante con métodos default?» Si dos interfaces aportan el mismo default, el compilador te obliga a resolverlo explícitamente con Interfaz.super.metodo(). No hay ambigüedad silenciosa.

static significa «pertenece a la clase, no a la instancia»; final significa «no se puede reasignar / heredar / sobrescribir», según dónde se aplique.

Lo importante en entrevista es lo que final no garantiza: que el objeto sea inmutable. final List<String> l = new ArrayList<>() impide reasignar l, pero no impide l.add(...).

Y hay un detalle de concurrencia que da muchos puntos: un campo final tiene una garantía especial del modelo de memoria. Si se inicializa en el constructor y no se filtra this, cualquier hilo que vea la referencia al objeto ve el valor correcto del campo sin sincronizar. Es la base de por qué los objetos inmutables son seguros de publicar.

Trampa: un static mutable es la fuente número uno de fugas de memoria y de bugs de concurrencia en aplicaciones Spring: una static Map que se usa de caché crece sin límite y nunca se libera, porque la clase vive mientras viva el classloader.

Un portador de datos inmutable y transparente: declaras los componentes y el compilador genera constructor canónico, accesores, equals, hashCode y toString. Existe para eliminar el ruido de las clases de datos y, sobre todo, para que equals/hashCode dejen de escribirse mal a mano.

public record CrearPedido(
        @NotBlank String clienteId,
        @NotEmpty List<Linea> lineas,
        @Positive BigDecimal total) {

    // Constructor compacto: validación e invariantes
    public CrearPedido {
        Objects.requireNonNull(clienteId);
        lineas = List.copyOf(lineas);              // copia defensiva: importante
        if (total.signum() <= 0) throw new IllegalArgumentException("total > 0");
    }
    // Métodos derivados sí, estado extra no
    public int numeroLineas() { return lineas.size(); }
    public record Linea(String sku, int cantidad, BigDecimal precio) { }
}

Dónde encaja perfecto: DTO de entrada y salida, objetos de valor del dominio (Dinero, Email, Rango), resultados de consulta (proyecciones), eventos, claves compuestas de mapas y, junto a sealed, tipos algebraicos para modelar «o esto o aquello».

Dónde no: entidades JPA (necesitan constructor sin argumentos, campos no finales y proxies para lazy), objetos que deben poder evolucionar ocultando su representación interna, y jerarquías con herencia de implementación —un record no puede extender una clase—.

Trampa: «¿es seguro entre hilos?». Sí, si todos sus componentes lo son. Un record Carrito(List<Linea> lineas) al que le pasas un ArrayList sin copiar es tan mutable y tan insegura como cualquier clase.

Para cerrar una jerarquía a un conjunto conocido y declarado de subtipos. Con eso el compilador puede comprobar que un switch cubre todos los casos, y tú puedes modelar «el resultado es A, B o C» sin excepciones, sin nulos y sin instanceof en cadena.

sealed interface Resultado<T> permits Ok, ErrorValidacion, NoEncontrado { }
record Ok<T>(T valor) implements Resultado<T> { }
record ErrorValidacion<T>(List<String> errores) implements Resultado<T> { }
record NoEncontrado<T>(String id) implements Resultado<T> { }

// El switch es una EXPRESIÓN y es exhaustivo: no hace falta default
ResponseEntity<?> aRespuesta(Resultado<PedidoDto> r) {
    return switch (r) {
        case Ok(var dto)              -> ResponseEntity.ok(dto);
        case ErrorValidacion(var errs)-> ResponseEntity.badRequest().body(errs);
        case NoEncontrado(var id)     -> ResponseEntity.notFound().build();
    };
}

El valor real está en el mantenimiento: el día que alguien añada record Conflicto(...) a la interfaz sellada, todos los switch del proyecto dejarán de compilar y te obligarán a decidir qué hacer en ese caso. Con una jerarquía abierta y un default, ese caso se habría colado en producción en silencio.

Trampa: si pones default en el switch, pierdes la exhaustividad y con ella la mitad del beneficio. Resiste la tentación de añadirlo «por seguridad».

Una clase con un número fijo de instancias creadas por la JVM, garantizadas únicas y seguras entre hilos. No es «una lista de constantes»: puede tener campos, constructor, métodos, implementar interfaces e incluso sobrescribir comportamiento por constante.

public enum EstadoPedido {
    NUEVO(true), PAGADO(true), ENVIADO(false), CANCELADO(false);

    private final boolean cancelable;
    EstadoPedido(boolean cancelable) { this.cancelable = cancelable; }
    public boolean esCancelable() { return cancelable; }

    // Máquina de estados dentro del propio enum: las reglas viven con el dato
    private static final Map<EstadoPedido, Set<EstadoPedido>> TRANSICIONES = Map.of(
        NUEVO,  EnumSet.of(PAGADO, CANCELADO),
        PAGADO, EnumSet.of(ENVIADO, CANCELADO),
        ENVIADO, EnumSet.noneOf(EstadoPedido.class),
        CANCELADO, EnumSet.noneOf(EstadoPedido.class));

    public boolean puedeIrA(EstadoPedido destino) {
        return TRANSICIONES.get(this).contains(destino);
    }
}

Tres cosas que dan puntos: el singleton más simple y seguro de Java es un enum de un solo elemento (resiste reflexión y serialización); EnumMap y EnumSet son implementaciones especializadas mucho más rápidas y compactas que HashMap/HashSet (un array indexado por ordinal y un mapa de bits, respectivamente); y con enum se puede usar == con total seguridad.

Trampa: nunca persistas ni serialices el ordinal(). Alguien insertará una constante nueva en medio de la lista y todos los datos históricos pasarán a significar otra cosa. En JPA, @Enumerated(EnumType.STRING) siempre; en JSON, el nombre.

Los genéricos son una comprobación del compilador. En el bytecode desaparecen: el tipo se reemplaza por su límite (normalmente Object) y el compilador inserta las conversiones necesarias. Se hizo así para mantener la compatibilidad binaria con el código anterior a Java 5.

List<String> a = new ArrayList<>();
List<Integer> b = new ArrayList<>();
a.getClass() == b.getClass();   // true: en ejecución las dos son ArrayList

// Lo que el borrado te impide hacer:
// new T[10]                     ← no se puede crear array de un genérico
// x instanceof List<String>     ← no compila; solo List<?>
// void f(List<String> l) {} y void f(List<Integer> l) {}  ← misma firma tras borrado
// catch (MiExcepcion<String> e) ← prohibido

// Y por eso, para deserializar un tipo parametrizado, hay que "colar" el tipo:
var lista = mapper.readValue(json, new TypeReference<List<PedidoDto>>() { });

El truco del TypeReference (o ParameterizedTypeReference en Spring) funciona porque el tipo genérico de una superclase sí se conserva en los metadatos de la clase: se crea una subclase anónima solo para guardar esa información.

Trampa: la repregunta es «¿qué es un tipo reified y qué lenguajes lo tienen?». Java no reifica los genéricos (C# y Kotlin con inline reified sí). Y ojo con la advertencia de unchecked cast: cuando la silencias con @SuppressWarnings("unchecked"), estás asumiendo tú una garantía que el compilador ya no puede darte, y el error saldrá como ClassCastException en un sitio lejano.

Producer Extends, Consumer Super. Si la estructura te da valores (productor), usa ? extends T; si recibe valores (consumidor), usa ? super T. Existe porque los genéricos en Java son invariantes: List<Perro> no es un List<Animal>, y los comodines son la forma de recuperar la flexibilidad sin perder la seguridad de tipos.

// Productor: solo leo de origen → extends
static <T> void copiar(List<? extends T> origen, List<? super T> destino) {
    for (T t : origen) destino.add(t);      // leer de origen: OK; escribir en destino: OK
}
copiar(List.of(new Perro()), new ArrayList<Animal>());   // compila

List<? extends Number> nums = List.of(1, 2, 3);
Number n = nums.get(0);   // ✅ leer sí
// nums.add(4);           // ❌ escribir no: el compilador no sabe si es List<Integer> o <Double>

List<? super Integer> sink = new ArrayList<Number>();
sink.add(42);             // ✅ escribir sí
Object o = sink.get(0);   // solo puedes leer como Object

Lo verás por todas partes en la API estándar sin haberte fijado: Collections.copy(List<? super T> dest, List<? extends T> src), Stream.map(Function<? super T, ? extends R>), Comparator.comparing(Function<? super T, ? extends U>).

Trampa: «¿y si la estructura hace las dos cosas?». Entonces no uses comodín: usa T exacto. Un tipo que produce y consume no puede ser ni covariante ni contravariante.

Checked para condiciones excepcionales pero previsibles y recuperables que el llamante debería tratar (el fichero no existe, el servicio remoto ha devuelto 503). Unchecked para errores de programación y violaciones de invariantes (argumento nulo, estado imposible, bug).

La realidad del mundo Spring es que la mayoría del código moderno usa unchecked: Spring convierte las SQLException en la jerarquía no comprobada de DataAccessException, y las lambdas de los streams no pueden lanzar checked, lo que obliga a envolver y ensucia el código. Una respuesta madura reconoce las dos posturas.

// Excepción de dominio propia: unchecked, con contexto útil y causa preservada
public class PedidoNoEncontrado extends RuntimeException {
    private final String pedidoId;
    public PedidoNoEncontrado(String pedidoId) {
        super("Pedido no encontrado: " + pedidoId);   // el mensaje incluye el dato
        this.pedidoId = pedidoId;                      // y el dato es accesible
    }
    public String pedidoId() { return pedidoId; }
}

// ❌ Lo que nunca se hace
try { hacerAlgo(); }
catch (Exception e) { }                        // tragar en silencio
catch (Exception e) { log.error("error"); }    // sin la causa ni contexto
catch (Exception e) { throw new RuntimeException(e.getMessage()); } // pierdes el stack

// ✅ Lo correcto
catch (IOException e) {
    throw new ImportacionFallida("fichero " + ruta + ", línea " + n, e);  // causa incluida
}

Tres reglas que valen más que la clasificación: no capturar sin actuar, no perder la causa, y añadir el contexto que el que lea el log necesita para reproducir (identificadores, no solo «error al procesar»).

Trampa: «¿capturarías Exception?». Solo en el límite del sistema: un @RestControllerAdvice, el bucle principal de un consumidor de mensajes o un scheduler, donde tragarte todo es preferible a que el hilo muera. Y ahí siempre se registra con stack trace completo. Capturar Throwable es otra cosa: te comerías OutOfMemoryError, y eso no se debe manejar.

Cierra automáticamente todo recurso que implemente AutoCloseable declarado en la cabecera, en orden inverso a su apertura, tanto en el camino normal como si hay excepción. Y hace algo que a mano casi nadie hacía bien: si el cierre falla, la excepción de cierre se añade como suppressed en lugar de reemplazar a la original.

// El patrón antiguo tenía un bug sutil: si close() lanzaba, perdías la excepción real
try (var conn = ds.getConnection();
     var ps = conn.prepareStatement("select * from pedido where id = ?")) {
    ps.setLong(1, id);
    try (var rs = ps.executeQuery()) {
        return mapear(rs);
    }
}   // se cierran rs, ps y conn en ese orden, pase lo que pase

// Java 9+: si la variable ya es final o effectively final, se puede usar directamente
var stream = Files.lines(ruta);
try (stream) { ... }

// Recuperar las excepciones suprimidas
catch (Exception e) {
    for (Throwable s : e.getSuppressed()) log.warn("fallo al cerrar", s);
}

Trampa: Files.lines(), Files.walk() y Files.newDirectoryStream() devuelven streams que abren un descriptor de fichero. Si no los pones en un try-with-resources, filtras descriptores hasta que el proceso muere con «too many open files». Es uno de los bugs más difíciles de detectar en desarrollo y uno de los más frecuentes en producción.

El finally gana: descarta el return anterior y, peor aún, se come cualquier excepción en curso. Es un antipatrón que oculta errores y que algunos analizadores estáticos marcan directamente como error.

int malo() {
    try { throw new IllegalStateException("boom"); }
    finally { return 1; }          // devuelve 1 y la excepción DESAPARECE
}

int confuso() {
    int x = 0;
    try { return x; }              // se evalúa x → 0 y se guarda ese valor
    finally { x = 99; }            // modificar x ya no cambia lo devuelto
}                                   // devuelve 0

// Con objeto mutable sí se ve el cambio, porque se devolvió la referencia:
List<String> tambienConfuso() {
    var l = new ArrayList<String>();
    try { return l; }
    finally { l.add("x"); }        // el llamante recibe [x]
}

La regla: en el finally solo va liberación de recursos, y a ser posible ni eso, porque para liberar recursos existe try-with-resources. Nunca return, nunca throw, nunca break ni continue.

Trampa: la repregunta es «¿se ejecuta siempre el finally?». Casi siempre, pero no si se llama a System.exit(), si la JVM se muere de forma anormal o si el hilo se detiene abruptamente. Es un buen detalle para demostrar precisión.

Optional existe para expresar en el tipo de retorno que un valor puede no estar, obligando al llamante a decidir qué hace. No es un sustituto universal de null ni un contenedor de propósito general.

// ✅ Uso correcto: retorno de una búsqueda que puede no encontrar nada
Optional<Cliente> buscarPorNif(String nif);

var nombre = buscarPorNif(nif)
        .map(Cliente::nombre)
        .map(String::toUpperCase)
        .orElse("DESCONOCIDO");

// orElseThrow con excepción de dominio: la forma más habitual en un servicio
var cliente = repo.findByNif(nif)
        .orElseThrow(() -> new ClienteNoEncontrado(nif));

// ❌ Abusos que se ven en entrevistas y en código real
if (opt.isPresent()) { usar(opt.get()); }        // es un if con más letras
opt.get();                                       // NoSuchElementException esperando a pasar
void f(Optional<String> p)                       // parámetro: usa sobrecarga o @Nullable
class Cliente { private Optional<String> tel; }  // campo: no es Serializable, ocupa más
List<Optional<Pedido>> lista;                    // una lista vacía ya expresa "nada"
return Optional.ofNullable(x).orElse(null);      // ida y vuelta absurda
opt.orElse(calcularCaro());                      // orElse SIEMPRE evalúa: usa orElseGet

La diferencia entre orElse y orElseGet es una pregunta muy frecuente: orElse evalúa su argumento aunque el Optional tenga valor, así que si el valor por defecto es una llamada costosa o con efectos secundarios, tienes un bug de rendimiento silencioso.

Trampa: «¿devolverías Optional<List<T>>?». No: para colecciones, la ausencia se representa con la colección vacía. Un Optional vacío y una lista vacía significan lo mismo y obligan al llamante a comprobar dos cosas.

Una lambda es una implementación concisa de una interfaz funcional (un solo método abstracto). Captura las variables locales por valor —de ahí la exigencia de que sean effectively final— y los campos de instancia por referencia a través de this.

int base = 10;
Function<Integer, Integer> f = x -> x + base;   // captura el VALOR 10
// base = 20;   ← si descomentas, la lambda deja de compilar

// Los campos sí se capturan por referencia (y ahí está el riesgo de concurrencia)
class Contador {
    private int n;                                  // campo mutable
    Runnable incrementar() { return () -> n++; }    // captura this: carrera si hay hilos
}

// Diferencia clave con las clases anónimas: this
class A {
    void m() {
        Runnable lambda   = () -> System.out.println(this);       // this = la instancia de A
        Runnable anonimo  = new Runnable() {
            public void run() { System.out.println(this); }        // this = el Runnable anónimo
        };
    }
}

El motivo real del effectively final es que la variable local vive en la pila del método, que puede haber terminado cuando la lambda se ejecute. Capturar por valor evita tener que decidir qué significaría escribir en una variable que ya no existe.

Trampa: «¿cómo acumulo un valor en un forEach?». Truco frecuente y mala idea: un array de un elemento o un AtomicInteger para saltarse la restricción. Si necesitas acumular, el forEach es la herramienta equivocada: usa reduce, collect o un bucle normal.

Son azúcar sintáctico para lambdas que solo llaman a un método existente. Hay cuatro formas, y conviene reconocer la tercera porque es la que confunde a todo el mundo:

// 1. Método estático                   Integer::parseInt      ≡ s -> Integer.parseInt(s)
// 2. Método de una instancia concreta   log::info              ≡ m -> log.info(m)
// 3. Método de instancia de un tipo     String::toUpperCase    ≡ s -> s.toUpperCase()
//    (el primer parámetro pasa a ser el receptor: ahí está el truco)
// 4. Constructor                        ArrayList::new         ≡ () -> new ArrayList<>()

var mayus = nombres.stream().map(String::toUpperCase).toList();
var mapa  = pedidos.stream().collect(toMap(Pedido::id, Function.identity()));
var set   = nombres.stream().collect(Collectors.toCollection(TreeSet::new));

// La forma 3 con dos argumentos: comparadores
lista.sort(String::compareToIgnoreCase);   // ≡ (a, b) -> a.compareToIgnoreCase(b)

Regla práctica de legibilidad: usa la referencia cuando el nombre del método ya explica lo que pasa, y una lambda cuando haga falta un nombre de parámetro que aporte significado. .filter(p -> p.esCancelable()) se lee peor que .filter(Pedido::esCancelable), pero .map(c -> c.getDireccion().getCiudad()) se lee mejor que cualquier acrobacia con referencias.

Trampa: this::metodo dentro de un bean de Spring captura this, así que si ese método está anotado con @Transactional o @Cacheable no pasa por el proxy y la anotación no se aplica. Es la misma trampa que la autoinvocación, pero disfrazada.

Porque las operaciones intermedias (map, filter, sorted…) no hacen nada al invocarlas: solo construyen la canalización. Nada se ejecuta hasta la operación terminal, y entonces cada elemento recorre toda la cadena antes de pasar al siguiente (fusión de bucles), lo que evita crear colecciones intermedias.

var s = List.of(1, 2, 3, 4, 5).stream()
        .peek(n -> System.out.println("map  " + n))
        .filter(n -> n % 2 == 0);
// Aquí no se ha impreso NADA todavía

var primero = s.findFirst();   // ahora sí: imprime "map 1", "map 2" y para

// Cortocircuito: no procesa el millón de elementos
var alguno = millon.stream().filter(caro).anyMatch(p -> p.total() > 1000);

// Ojo: sorted y distinct son "con estado" y necesitan ver todo (o casi)
// Stream.iterate infinito + limit funciona; + sorted no termina nunca

Consecuencias prácticas que dan puntos: un stream es de un solo uso (reutilizarlo lanza IllegalStateException); las operaciones de cortocircuito (findFirst, anyMatch, limit) pueden ahorrar casi todo el trabajo; y el orden de las operaciones importa: filtrar antes de mapear procesa menos elementos.

Trampa: peek es para depurar, no para efectos secundarios: con algunas fuentes y terminales la JVM puede omitirlo. Si necesitas un efecto por elemento, usa forEach.

map transforma un elemento en otro elemento (uno a uno); flatMap transforma un elemento en un stream de elementos y aplana el resultado (uno a muchos). En cuanto tu función de transformación devuelve una colección u otro Optional, lo que necesitas es flatMap.

record Pedido(String id, List<Linea> lineas) { }
record Linea(String sku, int cantidad) { }

// map → Stream<List<Linea>>: casi nunca es lo que quieres
Stream<List<Linea>> mal = pedidos.stream().map(Pedido::lineas);

// flatMap → Stream<Linea>: todas las líneas de todos los pedidos
var unidadesPorSku = pedidos.stream()
        .flatMap(p -> p.lineas().stream())
        .collect(Collectors.groupingBy(Linea::sku,
                 Collectors.summingInt(Linea::cantidad)));

// También con Optional, para evitar Optional<Optional<T>>
Optional<Ciudad> ciudad = buscarCliente(id)
        .flatMap(Cliente::direccion)    // direccion() devuelve Optional<Direccion>
        .map(Direccion::ciudad);

// Y mapMulti (Java 16+) evita crear un stream intermedio por elemento
var todas = pedidos.stream()
        .<Linea>mapMulti((p, consumidor) -> p.lineas().forEach(consumidor))
        .toList();

Trampa: el mismo patrón aparece en CompletableFuture (thenApply frente a thenCompose) y en Reactor (map frente a flatMap). Si dices que es el mismo concepto —aplanar un contenedor anidado, la operación bind de una mónada— demuestras que has entendido el patrón y no solo la API.

reduce combina los elementos de un stream en un solo valor con una función asociativa. Tiene tres sobrecargas, y la tercera es la que casi nadie sabe explicar.

// 1. Solo acumulador → Optional (el stream puede estar vacío)
Optional<BigDecimal> total = importes.stream().reduce(BigDecimal::add);

// 2. Con identidad → nunca vacío
BigDecimal total2 = importes.stream().reduce(BigDecimal.ZERO, BigDecimal::add);

// 3. Con identidad, acumulador y COMBINADOR: necesario cuando el tipo de
//    acumulación es distinto del tipo del elemento (y obligatorio en paralelo)
int caracteres = nombres.stream()
        .reduce(0,
                (acc, s) -> acc + s.length(),   // acumulador: (U, T) -> U
                Integer::sum);                   // combinador: (U, U) -> U

// ❌ El error clásico: reduce con un acumulador MUTABLE
var lista = palabras.stream()
        .reduce(new ArrayList<String>(), (l, s) -> { l.add(s); return l; }, (a, b) -> a);
// funciona en secuencial por accidente y corrompe datos en paralelo → usa collect()

Los requisitos que hay que nombrar: la función debe ser asociativa, la identidad debe ser una identidad de verdad (f(identidad, x) == x) y no debe haber estado mutable compartido. Si necesitas acumular en un contenedor mutable, la operación correcta es collect, que está diseñada para eso (con su supplier, acumulador y combinador).

Trampa: restar no es asociativo, así que reduce(0, (a,b) -> a - b) da resultados distintos en secuencial y en paralelo. Es un ejemplo perfecto para demostrar que entiendes el requisito.

Con seis u ocho colectores cubres el 95 % del código real. Merece la pena tenerlos en los dedos porque son petición habitual en un live coding.

record Venta(String vendedor, String region, BigDecimal importe, LocalDate fecha) { }

// Agrupar y contar
Map<String, Long> ventasPorRegion = ventas.stream()
        .collect(groupingBy(Venta::region, counting()));

// Agrupar y sumar dinero (reducing, porque summingDouble no vale para BigDecimal)
Map<String, BigDecimal> totalPorRegion = ventas.stream()
        .collect(groupingBy(Venta::region, TreeMap::new,
                 reducing(BigDecimal.ZERO, Venta::importe, BigDecimal::add)));

// Particionar (siempre devuelve las dos claves, true y false)
Map<Boolean, List<Venta>> grandes = ventas.stream()
        .collect(partitioningBy(v -> v.importe().compareTo(new BigDecimal("1000")) > 0));

// A mapa, con función de fusión OBLIGATORIA si puede haber claves repetidas
Map<String, Venta> ultimaPorVendedor = ventas.stream()
        .collect(toMap(Venta::vendedor, v -> v,
                 (a, b) -> a.fecha().isAfter(b.fecha()) ? a : b));

// Agrupar en dos niveles
Map<String, Map<Month, Long>> porRegionYMes = ventas.stream()
        .collect(groupingBy(Venta::region,
                 groupingBy(v -> v.fecha().getMonth(), counting())));

// Unir cadenas
String informe = ventas.stream().map(Venta::vendedor).distinct().sorted()
        .collect(joining(", ", "[", "]"));

// teeing (Java 12+): dos colectores a la vez en una sola pasada
record Resumen(long n, BigDecimal total) { }
var resumen = ventas.stream().collect(teeing(
        counting(),
        reducing(BigDecimal.ZERO, Venta::importe, BigDecimal::add),
        Resumen::new));

Trampa: toMap sin función de fusión lanza IllegalStateException con claves duplicadas, y además no admite valores null (a diferencia de groupingBy, que sí puede acabar con listas vacías). Los dos son fallos que aparecen solo con datos reales, nunca con los tres elementos del test.

Cuando el bucle sea más legible o cuando el stream te obligue a acrobacias. La respuesta madura no es «streams para todo», es reconocer que son una herramienta de expresión de transformaciones de datos y que fuera de ese caso estorban.

// Stream retorcido para conseguir el índice: señal de que quieres un bucle
IntStream.range(0, lista.size())
         .filter(i -> i % 2 == 0)
         .mapToObj(i -> i + ": " + lista.get(i))
         .forEach(System.out::println);

// El bucle equivalente se entiende sin pensar
for (int i = 0; i < lista.size(); i += 2) {
    System.out.println(i + ": " + lista.get(i));
}

Trampa: si dices «los streams son más lentos», te van a pedir un número. La verdad es que la diferencia es despreciable en la inmensa mayoría del código (y en bucles muy calientes con primitivos puede ser de un 10-30 % a favor del bucle). La legibilidad manda salvo que un perfil diga lo contrario.

Sí, es inferencia de tipo en variables locales, resuelta en compilación: Java sigue siendo de tipado estático y var no tiene nada que ver con el var de JavaScript. Sirve para eliminar la repetición del tipo cuando ya es obvio por el lado derecho.

// ✅ Donde mejora: el tipo está a la vista
var pedidos = new ArrayList<Pedido>();
var entrada = Map.entry("clave", List.of(1, 2, 3));
for (var e : mapa.entrySet()) { ... }
try (var conn = ds.getConnection()) { ... }

// ❌ Donde empeora: el tipo se pierde
var x = servicio.procesar(id);          // ¿qué devuelve? hay que ir a mirar
var lista = new ArrayList<>();          // ArrayList<Object>: sorpresa desagradable
var r = 0;                               // int, no long; cuidado con desbordar

// Donde NO se puede usar
// var campo = 1;              ← campos de clase
// void f(var p)               ← parámetros
// var f() { return 1; }       ← tipos de retorno
// var x;                      ← sin inicializador
// var x = null;               ← no hay tipo que inferir

Norma de equipo razonable: var cuando el tipo aparezca en la misma línea (un new, un literal, un cast), y tipo explícito cuando el valor venga de una llamada cuyo retorno no sea evidente. Es una decisión de legibilidad, y conviene que esté acordada en el proyecto.

Trampa: var con tipos anónimos o intersecciones infiere un tipo que no puedes escribir, y eso puede propagarse de formas raras. Y en un for con var i = 0 sobre un contador que llega a miles de millones, acabas con un int desbordado donde querías un long.

Cadenas multilínea sin escapes ni concatenación, con la indentación incidental eliminada de forma automática. Resuelven el problema real de tener SQL, JSON o HTML dentro de código Java, que antes era ilegible y propenso a errores.

String sql = """
        SELECT p.id, p.total, c.nombre
          FROM pedido p
          JOIN cliente c ON c.id = p.cliente_id
         WHERE p.creado_en >= ?
         ORDER BY p.creado_en DESC
        """;

String json = """
        { "clienteId": "%s", "total": %.2f }
        """.formatted(clienteId, total);   // formatted() está pensado para esto

// Reglas que preguntan:
// · La comilla triple de apertura debe ir seguida de salto de línea.
// · La indentación se calcula con la línea menos indentada, INCLUIDA la de cierre:
//   mover la comilla de cierre a la izquierda cambia la indentación de todo el bloque.
// · \ al final de línea une líneas sin meter el salto.
// · \s conserva un espacio final que si no se eliminaría.
// · No hay interpolación de variables: usa formatted() o concatena.

Trampa: un text block no valida nada. Meter SQL con concatenación de variables dentro de un bloque de texto sigue siendo inyección SQL; los parámetros van con ? o con nombres, igual que antes. La legibilidad no es seguridad.

Cuatro cosas: los tipos son inmutables y seguros entre hilos, el modelo distingue conceptos que antes se mezclaban, la aritmética es explícita, y el formateo se hace con DateTimeFormatter, que sí es seguro entre hilos —SimpleDateFormat no lo era y causaba corrupción silenciosa cuando se guardaba en un campo estático—.

// Inyecta un Clock: hace los tests deterministas sin librerías de magia
@Service class ServicioPedidos {
    private final Clock clock;
    ServicioPedidos(Clock clock) { this.clock = clock; }
    Pedido crear(...) { return new Pedido(..., Instant.now(clock)); }
}
// En el test: Clock.fixed(Instant.parse("2026-03-30T02:30:00Z"), ZoneOffset.UTC)

// Aritmética con horario de verano: solo ZonedDateTime lo hace bien
var madrid = ZoneId.of("Europe/Madrid");
var antes = ZonedDateTime.of(2026, 3, 28, 23, 0, 0, 0, madrid);
antes.plusDays(1);        // respeta el cambio de hora del 29 de marzo
antes.plusHours(24);      // NO es lo mismo: suma 24 horas exactas

Trampa: guardar LocalDateTime en la base de datos para un sistema con usuarios en varias zonas. Funciona hasta que hay que comparar dos registros creados en zonas distintas, o hasta el último domingo de octubre, cuando la misma hora local existe dos veces. La regla es: almacena en UTC (Instant / timestamptz) y convierte a zona solo al mostrar.

Porque double es coma flotante binaria (IEEE 754) y no puede representar exactamente la mayoría de los decimales, así que los errores se acumulan y aparecen descuadres de céntimos que en contabilidad son inaceptables.

System.out.println(0.1 + 0.2);                    // 0.30000000000000004
System.out.println(1.03 - 0.42);                  // 0.6100000000000001

// ❌ El error dentro del error: construir BigDecimal desde double
new BigDecimal(0.1);      // 0.1000000000000000055511151231257827021181583404541015625
// ✅ Siempre desde String o con valueOf
new BigDecimal("0.1");    // exacto
BigDecimal.valueOf(0.1);  // usa Double.toString: aceptable, pero String es mejor

// Escala y redondeo explícitos, y comparación con compareTo
var precio = new BigDecimal("19.99");
var total  = precio.multiply(BigDecimal.valueOf(3))
                   .setScale(2, RoundingMode.HALF_UP);      // 59.97

new BigDecimal("1.0").equals(new BigDecimal("1.00"));       // false (escala distinta)
new BigDecimal("1.0").compareTo(new BigDecimal("1.00")) == 0; // true ← usa este

// División: SIEMPRE con escala y redondeo, o ArithmeticException con 1/3
var unitario = total.divide(BigDecimal.valueOf(3), 2, RoundingMode.HALF_UP);

Alternativa válida y a veces mejor: guardar los importes en céntimos como long (lo que hacen muchas pasarelas de pago, incluida Stripe). Es más rápido y no tiene sorpresas de escala, a costa de tener que recordar el factor y de complicarse con divisiones y con monedas de tres decimales.

Trampa: la repregunta es «¿y en la base de datos?». numeric(19,4) o decimal, nunca float/double precision. Y en JPA, @Column(precision = 19, scale = 4) con BigDecimal. Si en algún punto de la cadena hay un double, el resto de las precauciones no sirven de nada.

Porque deserializar un flujo binario con ObjectInputStream es, en la práctica, ejecutar código elegido por quien envió los datos. La deserialización construye objetos arbitrarios sin pasar por los constructores y ejecuta readObject; encadenando clases presentes en el classpath (gadget chains) se puede conseguir ejecución remota. Es el origen de vulnerabilidades muy conocidas y el motivo de que la propia especificación de Java la considere un error de diseño histórico.

// ❌ Nunca deserialices datos que vengan de fuera
var obj = new ObjectInputStream(peticionHttp.getInputStream()).readObject();

// ✅ Usa un formato de datos, no de objetos: JSON con un DTO explícito
record PedidoDto(String id, BigDecimal total) { }
var dto = mapper.readValue(cuerpo, PedidoDto.class);

// Si NO puedes evitarla, filtra las clases permitidas (Java 9+, JEP 290)
var in = new ObjectInputStream(entrada);
in.setObjectInputFilter(ObjectInputFilter.Config.createFilter(
        "com.miempresa.dominio.*;java.util.*;!*"));   // lista blanca y deniega el resto

Otros motivos para evitarla aunque no haya atacante: acopla tu formato de almacenamiento a la estructura interna de tus clases, cualquier refactor rompe la compatibilidad, y serialVersionUID es una fuente inagotable de errores. Para persistir o transportar, siempre un formato explícito (JSON, Avro, Protobuf) con su esquema versionado.

Trampa: esto también aplica a lo que parece inocente: sesiones HTTP serializadas en Redis, cachés distribuidas y colas que transportan objetos Java. Si un atacante puede escribir en ese almacén, tiene ejecución de código. Configura serializadores JSON explícitos en Spring Session y en Spring Data Redis, y desactiva el default typing de Jackson.

La respuesta que puntúa no es una lista de los 23 del GoF: es reconocerlos donde ya están y usar tres o cuatro con criterio. Los que aparecen todos los días:

// Strategy con inyección de un Map: Spring rellena las claves con el nombre del bean
@Service
class CalculadoraImpuestos {
    private final Map<String, EstrategiaImpuesto> estrategias;   // "es", "pt", "fr"…

    CalculadoraImpuestos(Map<String, EstrategiaImpuesto> estrategias) {
        this.estrategias = estrategias;
    }
    BigDecimal calcular(String pais, BigDecimal base) {
        return estrategias.getOrDefault(pais, estrategias.get("default")).aplicar(base);
    }
}
// Añadir un país = añadir una clase con @Component("pt"). Cero cambios aquí.

Trampa: si nombras Singleton, te van a preguntar cómo lo implementas de forma segura y por qué en Spring no hace falta (el contenedor gestiona una instancia por ApplicationContext, que no es lo mismo que el patrón Singleton clásico con un static). Y si nombras un patrón, tienes que poder decir qué problema resuelve y cuál es su coste; nombrarlo sin eso resta.

Con tres preguntas, en este orden: ¿qué operación se hace más veces?, ¿necesito orden? y ¿hay concurrencia?. La complejidad asintótica es el último criterio, no el primero, porque con pocos miles de elementos la localidad de memoria pesa más que la notación O grande.

Trampa: la repregunta habitual es «¿y si no sabes cuántos elementos habrá?». Respuesta: ArrayList o HashMap y, si tienes una estimación, pásala al constructor para evitar redimensionados —new HashMap<>(esperados / 0.75f + 1)—. Ese detalle demuestra que sabes lo que cuesta un resize.

La respuesta correcta es casi siempre ArrayList, incluso en los casos que el libro de texto asigna a LinkedList. La tabla teórica dice que insertar en medio es O(1) en la lista enlazada y O(n) en el array, pero esa tabla ignora dos cosas decisivas.

Las dos razones por las que la intuición falla: (1) System.arraycopy está implementado en código nativo vectorizado y mueve megabytes por milisegundo, así que «desplazar n elementos» es ridículamente rápido; y (2) la localidad de caché: un array contiguo se lee de la caché L1/L2, mientras que recorrer nodos dispersos provoca un acceso a memoria principal por elemento, que cuesta unas cien veces más.

Cuándo LinkedList gana de verdad: prácticamente nunca en código de aplicación. Si necesitas una cola por los dos extremos, ArrayDeque es mejor que las dos. Si insertas y borras mucho en medio manteniendo posición, probablemente necesites otra estructura entera (un TreeMap, una lista enlazada propia con acceso a los nodos, o un índice).

Trampa: te pueden preguntar «¿y para implementar una LRU?». Ahí sí hace falta una lista doblemente enlazada, pero con acceso directo a los nodos desde un mapa; eso es exactamente lo que hace LinkedHashMap por dentro y por eso no se implementa a mano.

Un array de buckets cuyo índice se obtiene del hash de la clave. Los pasos exactos, que es lo que quieren oír:

1. h = clave.hashCode()
2. Mezcla:  h ^= (h >>> 16)      ← propaga los bits altos a los bajos
3. Índice:  i = h & (n - 1)      ← n es potencia de 2, así que es un AND en vez de un módulo
4. En el bucket i:
   · vacío            → se crea la entrada
   · lista enlazada   → se compara hash y luego equals() con cada nodo
   · árbol rojo-negro → búsqueda O(log k)
5. Si el bucket supera TREEIFY_THRESHOLD (8) y la tabla tiene ≥ 64 buckets,
   la lista se convierte en árbol. Si baja de UNTREEIFY_THRESHOLD (6), vuelve a lista.
6. Si size > capacidad × loadFactor (0.75), la tabla DUPLICA su tamaño y se
   redistribuyen todas las entradas (rehash).

Por qué cada decisión: la mezcla del paso 2 existe porque el índice solo usa los bits bajos, y muchos hashCode reales solo varían en los altos (por ejemplo, objetos con el mismo prefijo). La potencia de dos permite sustituir un módulo por un AND, que es una instrucción en lugar de una división. El árbol se añadió en Java 8 para que un ataque de colisiones (mandar miles de claves con el mismo hash) degradara a O(log n) en lugar de a O(n), que era una vulnerabilidad de denegación de servicio real.

Rendimiento: O(1) medio, O(log n) en el peor caso desde Java 8. Y un detalle práctico: el resize es la operación caliente escondida. Si vas a meter un millón de entradas, dimensiona el mapa al crearlo o pagarás unos veinte redimensionados con rehash completo.

Trampa: «¿está garantizado el orden de iteración?» No, y además puede cambiar entre versiones de Java y entre ejecuciones. Si tu código depende del orden de un HashMap, tienes un bug esperando: usa LinkedHashMap o TreeMap.

Que la entrada se vuelve inalcanzable. El bucket se eligió con el hash antiguo; al mutar el campo que participa en hashCode, el nuevo hash apunta a otro bucket, así que get busca donde no está y remove tampoco lo encuentra. La entrada sigue ocupando memoria y aparece al iterar, lo que produce la escena desconcertante de un mapa que «contiene» algo que no puedes recuperar.

class ClaveMutable {
    String valor;
    ClaveMutable(String v) { valor = v; }
    @Override public int hashCode() { return valor.hashCode(); }
    @Override public boolean equals(Object o) {
        return o instanceof ClaveMutable c && valor.equals(c.valor);
    }
}

var k = new ClaveMutable("a");
var mapa = new HashMap<ClaveMutable, String>();
mapa.put(k, "valor");
k.valor = "b";                       // mutamos la clave YA insertada

mapa.get(k);            // null   ← busca en el bucket de "b"
mapa.get(new ClaveMutable("a"));  // null ← busca en el de "a", pero equals falla
mapa.size();            // 1      ← sigue ahí, pero es basura inaccesible
mapa.remove(k);         // no borra nada

La regla: las claves de un mapa y los elementos de un Set deben ser inmutables, o al menos deben ser inmutables los campos que participan en equals/hashCode. Por eso String, los envoltorios numéricos, los enum y los record con componentes inmutables son las claves ideales.

Trampa: el caso real más frecuente es una entidad JPA usada como clave con equals basado en el id. Metes la entidad nueva en un Set cuando su id es null, Hibernate hace flush, asigna el id y el hash cambia. Solución: equals/hashCode por clave de negocio, o por id con un hash constante por tipo (que es lo que recomienda la propia documentación de Hibernate).

Uno que distribuye mal: muchas claves distintas caen en el mismo bucket. El extremo absurdo es return 1, que es formalmente correcto (cumple el contrato) y convierte el mapa en una lista enlazada: todas las operaciones pasan de O(1) a O(n) —o a O(log n) desde Java 8, gracias a la treeificación—.

// ❌ Correcto pero catastrófico
@Override public int hashCode() { return 1; }

// ❌ Casi tan malo: campos con poca variabilidad
@Override public int hashCode() { return activo ? 1 : 0; }   // 2 buckets para 1 M de objetos

// ❌ Malo de otra forma: caro de calcular y se llama muchísimo
@Override public int hashCode() { return Objects.hash(listaDeMilElementos); }

// ✅ Bien: campos discriminantes e inmutables
@Override public int hashCode() { return Objects.hash(nif, tipo); }

// ✅ Si el objeto es inmutable y el hash es caro, cachéalo (lo hace String)
private int hash;   // 0 = no calculado
@Override public int hashCode() {
    int h = hash;
    if (h == 0) hash = h = Objects.hash(campoA, campoB, campoC);
    return h;
}

Cómo se detecta en producción: un método que parece trivial aparece caliente en el perfilador (HashMap.getNode o tu propio equals con un número absurdo de llamadas), o el tiempo de una operación crece de forma lineal con el número de elementos cuando debería ser plano. Se confirma contando, en un test, cuántas claves distintas producen el mismo hash sobre datos reales.

Trampa: «¿usarías el hashCode para nada más?». Nunca para persistir, ni para deduplicar entre ejecuciones, ni como identificador: no es estable entre JVM ni entre versiones, y para Object depende de la dirección de memoria. Si necesitas un hash estable, usa SHA-256 sobre una representación canónica.

Cuando necesites orden o consultas por rango. TreeMap es un árbol rojo-negro: mantiene las claves ordenadas por su orden natural o por un Comparator, con O(log n) en las operaciones básicas, y ofrece una API de navegación que HashMap no puede dar.

// Tarifas por tramo: "¿qué tarifa aplica a 1.750 unidades?"
var tarifas = new TreeMap<Integer, BigDecimal>();
tarifas.put(0,    new BigDecimal("1.00"));
tarifas.put(1000, new BigDecimal("0.80"));
tarifas.put(5000, new BigDecimal("0.60"));

var tarifa = tarifas.floorEntry(1750).getValue();   // 0.80 ← el tramo que empieza en 1000

// Rango de fechas sin filtrar toda la colección
var eventos = new TreeMap<Instant, Evento>();
var deLaSemana = eventos.subMap(inicioSemana, true, finSemana, false);

// Otras operaciones útiles: firstKey, lastKey, higherKey, ceilingKey, headMap,
// tailMap, descendingMap, pollFirstEntry (útil para colas de vencimientos).

Detalle importante: TreeMap usa compareTo/compare, no equals, para decidir si dos claves son la misma. Si tu Comparator es inconsistente con equals, tendrás resultados sorprendentes (dos claves «iguales» para el comparador se sobrescriben aunque no sean equals). Y no admite claves null.

Trampa: si solo necesitas «los datos ordenados al mostrar», no uses TreeMap: usa HashMap y ordena al final, o mejor, ordena en la base de datos con un ORDER BY que use un índice. Pagar O(log n) en cada escritura para un orden que solo necesitas una vez es un mal negocio.

Con LinkedHashMap en modo orden de acceso y sobrescribiendo removeEldestEntry. Es la respuesta corta y correcta; la respuesta completa añade por qué funciona y qué usarías en producción.

public class CacheLru<K, V> extends LinkedHashMap<K, V> {
    private final int capacidad;

    public CacheLru(int capacidad) {
        super(16, 0.75f, true);        // true = orden de ACCESO, no de inserción
        this.capacidad = capacidad;
    }
    @Override protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > capacidad;      // se llama después de cada put
    }
}

var cache = new CacheLru<String, Cliente>(3);
cache.put("a", a); cache.put("b", b); cache.put("c", c);
cache.get("a");                 // "a" pasa a ser el más reciente
cache.put("d", d);              // expulsa "b", que es el menos usado recientemente

Funciona porque LinkedHashMap mantiene, además de la tabla hash, una lista doblemente enlazada con todas las entradas: en modo acceso, cada get mueve el nodo al final en O(1). Eso da lo mejor de las dos estructuras: búsqueda O(1) y orden de uso mantenido sin recorrer nada.

Lo que hay que decir después, y es lo que distingue la respuesta: en producción usaría Caffeine. Esta implementación no es segura entre hilos (envolverla con Collections.synchronizedMap serializa todos los accesos), no tiene expiración por tiempo, no tiene carga asíncrona, no da métricas y usa LRU puro, que se comporta mal con barridos secuenciales. Caffeine resuelve todo eso con el algoritmo W-TinyLFU y es la implementación por defecto de Spring Cache.

Trampa: «¿y si son varias instancias del servicio?». Entonces una caché en memoria significa que cada instancia tiene datos distintos, y hay que decidir si eso es tolerable. Si no lo es, caché distribuida (Redis) y asumir la latencia de red y la invalidación.

EnumMap es un array indexado por el ordinal() de la constante. No calcula hash, no tiene colisiones, no redimensiona y su iteración sigue el orden de declaración del enum. Es entre dos y cinco veces más rápido que HashMap y ocupa mucho menos.

// Contadores por estado: la forma idiomática
var porEstado = new EnumMap<EstadoPedido, Integer>(EstadoPedido.class);
for (var p : pedidos) porEstado.merge(p.estado(), 1, Integer::sum);
// La iteración sale en orden: NUEVO, PAGADO, ENVIADO, CANCELADO

// EnumSet es un mapa de bits: un long cubre hasta 64 constantes
var cancelables = EnumSet.of(EstadoPedido.NUEVO, EstadoPedido.PAGADO);
if (cancelables.contains(pedido.estado())) { ... }     // una operación de bits

var todosMenosEnviado = EnumSet.complementOf(EnumSet.of(EstadoPedido.ENVIADO));
var rango = EnumSet.range(EstadoPedido.NUEVO, EstadoPedido.ENVIADO);

La regla es sencilla: si la clave es un enum, usa EnumMap; si es un conjunto de enum, usa EnumSet. Es una de esas mejoras que no cuestan nada y que demuestran que conoces la biblioteca estándar más allá de lo básico.

Trampa: aunque EnumMap usa internamente el ordinal, eso es un detalle de implementación y no te obliga a persistirlo. Sigue guardando el nombre en base de datos y en JSON.

Tres cosas distintas que se confunden constantemente:

// 1. List.of / Map.of / Set.of (Java 9+): verdaderamente inmutables
var a = List.of("x", "y");
a.add("z");                       // UnsupportedOperationException
// Ojo: NO admiten null (ni claves ni valores) y Map.of falla con claves duplicadas

// 2. List.copyOf: copia inmutable de otra colección
var origen = new ArrayList<>(List.of("x"));
var copia = List.copyOf(origen);  // snapshot: si origen cambia, copia NO cambia
origen.add("y");                  // copia sigue siendo [x]

// 3. Collections.unmodifiableList: VISTA de solo lectura, no una copia
var vista = Collections.unmodifiableList(origen);
vista.add("z");                   // UnsupportedOperationException
origen.add("z");                  // ¡vista ahora contiene z! ← la trampa

// 4. Y el más traicionero: Arrays.asList
var fija = Arrays.asList("a", "b");
fija.set(0, "c");                 // ✅ funciona (es una vista del array)
fija.add("d");                    // ❌ UnsupportedOperationException (tamaño fijo)

Cuándo usar cada uno: List.of para constantes y literales; List.copyOf para copias defensivas en constructores y en getters, que es lo que hace segura una clase inmutable; unmodifiableList solo cuando quieras exponer una vista viva a propósito y el llamante entienda que puede cambiar bajo sus pies.

Trampa: «¿son inmutables los elementos?». No: son colecciones inmutables de referencias. List.of(pedido) no impide llamar a pedido.setTotal(...). La inmutabilidad profunda exige que los elementos también lo sean.

Porque los iteradores de las colecciones no concurrentes son fail-fast: guardan un contador de modificaciones (modCount) y si detectan que la colección cambió por otra vía durante la iteración, abortan. Y ojo, el nombre engaña: el caso más frecuente es un solo hilo, no una carrera.

// ❌ Un hilo, excepción garantizada
for (var p : pedidos) {
    if (p.estaCancelado()) pedidos.remove(p);      // ConcurrentModificationException
}

// ✅ Opción 1: iterator.remove()
var it = pedidos.iterator();
while (it.hasNext()) { if (it.next().estaCancelado()) it.remove(); }

// ✅ Opción 2 (la idiomática): removeIf
pedidos.removeIf(Pedido::estaCancelado);

// ✅ Opción 3: construir una colección nueva (mejor si además transformas)
var vivos = pedidos.stream().filter(p -> !p.estaCancelado()).toList();

// ✅ Opción 4, con concurrencia real: colección concurrente
var compartida = new CopyOnWriteArrayList<Pedido>();   // iterar es sobre un snapshot
var mapa = new ConcurrentHashMap<String, Pedido>();     // iteración débilmente consistente

Matiz que da puntos: la excepción es best-effort, no una garantía. Con varios hilos puede no lanzarse y dejar que leas datos inconsistentes, así que no la uses como mecanismo de detección de errores de concurrencia. Y las colecciones concurrentes no la lanzan porque sus iteradores son weakly consistent: reflejan algunos cambios y otros no, pero nunca fallan.

Trampa: el caso oculto es borrar el penúltimo elemento de un ArrayList en un for-each: por cómo está implementado hasNext(), el bucle termina antes de comprobar el modCount y no lanza excepción, simplemente se salta un elemento en silencio. Ese es un bug mucho peor que la excepción.

Desde Java 8 no usa segmentos con cerrojos: usa CAS para el caso sin contención y sincronización por nodo (cabeza del bucket) cuando hay colisión. Eso significa que las lecturas son completamente libres de cerrojos y que dos escrituras en buckets distintos no se estorban.

Estructura: la misma tabla de buckets que HashMap (con treeificación),
pero con nodos volátiles.

· Lectura (get): sin cerrojos. Los campos val y next son volatile, así que se
  ve un valor consistente sin sincronizar.
· Escritura en bucket vacío: CAS sobre la posición de la tabla. Si falla,
  se reintenta (otro hilo llegó antes).
· Escritura en bucket ocupado: synchronized sobre el primer nodo del bucket.
  Solo bloquea ese bucket, no el mapa.
· Tamaño: no hay un contador único (sería un punto de contención). Usa un
  array de celdas al estilo LongAdder → size() es una aproximación coherente,
  no una foto exacta bajo escritura concurrente.
· Resize: colaborativo. Varios hilos ayudan a transferir buckets a la tabla nueva.

La parte que importa en la práctica: cada operación individual es atómica, pero una secuencia de operaciones no lo es. Por eso existen los métodos compuestos, que son los que hay que usar:

// ❌ Carrera: entre containsKey y put puede colarse otro hilo
if (!mapa.containsKey(k)) mapa.put(k, cargar(k));

// ✅ Atómico
mapa.computeIfAbsent(k, this::cargar);
mapa.merge(clave, 1L, Long::sum);              // contador concurrente
mapa.putIfAbsent(k, v);
mapa.compute(k, (key, viejo) -> viejo == null ? 1 : viejo + 1);

Dos avisos sobre computeIfAbsent: la función se ejecuta con el bucket bloqueado, así que debe ser rápida y no debe tocar el mismo mapa (si lo hace, puedes provocar un bloqueo o corromper la estructura). Si la carga es lenta (una llamada remota), guarda un CompletableFuture como valor en lugar del resultado.

Trampa: no admite claves ni valores null, y es a propósito: con null permitido, get(k) == null sería ambiguo entre «no está» y «está con valor nulo», y en concurrencia no podrías distinguirlos ni con containsKey.

Las que de verdad se usan son media docena, y lo importante es el criterio de elección:

Y el punto que hay que añadir siempre: la mejor colección concurrente es ninguna. Si puedes evitar el estado mutable compartido —pasando datos inmutables entre hilos, confinando el estado en un solo hilo o usando el resultado de un CompletableFuture— te ahorras toda esta categoría de problemas.

Trampa: CopyOnWriteArrayList con escrituras frecuentes es un desastre: cada add copia el array entero, así que insertar n elementos es O(n²). Se ha visto usada «porque es thread-safe» en bucles de escritura y tumbar un servicio.

Es el coste medio por operación a lo largo de una secuencia, no el coste del peor caso individual. Se usa cuando una operación es casi siempre baratísima y de vez en cuando caríssima, y el reparto de ese coste es lo que importa. Se usa cuando una operación es casi siempre baratísima y de vez en cuando muy costosa.

ArrayList con capacidad 10. add() al final:
· Las 10 primeras: O(1) cada una (escribir en el array).
· La 11ª: hay que crear un array de 15 (crecimiento de 1,5×) y copiar 10 → O(n).
· Las siguientes 4: O(1)…

¿Por qué el total es O(1) amortizado?
Al crecer multiplicando (no sumando), las copias se hacen cada vez más raras.
Insertar n elementos cuesta:  n + (n/2 + n/4 + n/8 + …) < n + n = 2n
Total O(n) para n inserciones → O(1) por inserción.

Si el array creciera de 10 en 10, habría n/10 copias de coste medio n/2
→ O(n²) en total → O(n) por inserción. La multiplicación es la clave.

Dónde importa en el mundo real: (1) en un sistema con requisitos de latencia estricta, ese O(n) ocasional es un pico de p99 y conviene dimensionar la lista al crearla; (2) el mismo razonamiento explica el resize de HashMap y el crecimiento de StringBuilder; (3) es la respuesta a «¿por qué ArrayList es O(1) al final si a veces copia todo?».

Trampa: no confundas amortizado con caso medio. Amortizado es una garantía sobre cualquier secuencia de operaciones; caso medio es una afirmación probabilística sobre la entrada. HashMap.get es O(1) en caso medio (depende del hash); ArrayList.add es O(1) amortizado (garantizado).

Más de lo que parece, y saber estimarlo es lo que te permite responder «¿caben diez millones de estos en memoria?» sin adivinar. En una JVM de 64 bits con punteros comprimidos (por defecto por debajo de 32 GB de heap):

Cabecera de objeto:      12 bytes (mark word 8 + class pointer 4 comprimido)
Referencia:               4 bytes (comprimida) / 8 sin comprimir
int, float:               4 bytes      long, double: 8 bytes
boolean, byte:            1 byte       char, short:  2 bytes
Alineación:               el tamaño total se redondea a múltiplo de 8

Ejemplo: class Punto { int x; int y; }
  12 (cabecera) + 4 + 4 = 20 → alineado a 24 bytes

Ejemplo: Integer                    → 16 bytes (12 + 4)
Ejemplo: Long                       → 16 bytes (12 + 8 = 20 → 24, con padding)
Ejemplo: String "hola"              → objeto 24 + byte[] 24 ≈ 48 bytes por 4 caracteres
Ejemplo: entrada de HashMap         → nodo ~32 bytes + clave + valor + hueco en la tabla
Ejemplo: nodo de LinkedList         → 24 bytes solo de estructura, por elemento

Por eso:
· Un ArrayList<Integer> de 1 M ≈ 4 MB de array + 16 MB de Integers = 20 MB
· Un int[] de 1 M                 = 4 MB   ← cinco veces menos
· Un HashMap<Long, Long> de 1 M    ≈ 80-100 MB

Consecuencias prácticas: el boxing multiplica la memoria y añade indirección, así que en estructuras grandes de números merece la pena un array primitivo o una librería especializada (fastutil, Eclipse Collections). Y una List<String> con millones de cadenas repetidas es un candidato ideal para deduplicar.

Trampa: te pueden preguntar cómo lo mides en lugar de estimarlo. Con un heap dump y el árbol de dominadores (Eclipse MAT, VisualVM), o con -XX:+UseCompressedOops y la librería JOL (Java Object Layout), que imprime el diseño exacto de una clase. Estimar sirve para diseñar; medir es lo que se hace cuando ya hay un problema.

Midiendo, en este orden, y no cambiando código a ciegas —que es el error que quiere descartar esta pregunta—.

1. Confirmar dónde está el tiempo, no suponerlo. Un perfilador de muestreo con bajo impacto (async-profiler o JFR) en el entorno lo más parecido a producción. Si el 80 % del tiempo está en esperar a la base de datos, cualquier optimización de colecciones es irrelevante.
2. Leer el gráfico de llamas. Buscar frames sospechosos: HashMap.getNode, tu propio equals, ArrayList.indexOf (una búsqueda lineal escondida), System.arraycopy (redimensionados) o Arrays.sort.
3. Mirar la asignación de memoria, no solo la CPU. JFR tiene un perfil de allocation: si una estructura genera basura a razón de gigabytes por minuto, el coste aparece como tiempo de GC en otro sitio.
4. Comprobar la complejidad empíricamente. Duplica el tamaño de la entrada y mide: si el tiempo se cuadruplica, tienes un O(n²) escondido —el clásico es un contains sobre una List dentro de un bucle—.
5. Medir el cambio con un microbenchmark serio (JMH), con warm-up y varias iteraciones. Sin JMH, lo que mides es el JIT calentándose y no tu código.
6. Verificar en producción con una métrica antes y después. Si no puedes demostrar la mejora con un número, no sabes si has mejorado.

// El O(n²) escondido más frecuente de todos
for (var pedido : pedidos) {                       // n
    if (idsBloqueados.contains(pedido.id())) {     // List.contains → O(m)
        ...
    }
}
// Arreglo de una línea: idsBloqueados como Set<String> → O(1)
// Con 10.000 pedidos y 10.000 bloqueados: de 100 M de comparaciones a 10.000.

Trampa: si dices «usaría System.currentTimeMillis() antes y después», te van a preguntar por el calentamiento del JIT, por el GC y por el ruido del sistema. Nombrar JMH y explicar por qué hace falta calentamiento es la diferencia entre una respuesta de junior y una de senior.

Casi nunca en una aplicación web, y solo tras medir. Los requisitos para que ayude son cuatro y hay que cumplirlos todos: muchos datos ya en memoria (decenas de miles como mínimo), coste por elemento apreciable, operaciones puras sin bloqueo ni estado compartido y una fuente que se parta bien (un ArrayList o un array sí; una LinkedList o Files.lines, mal).

El motivo por el que es peligroso en un servidor: parallelStream usa el ForkJoinPool.commonPool(), que es compartido por toda la JVM y tiene núcleos - 1 hilos. Si una petición lanza un stream paralelo con una operación bloqueante, secuestra ese pool y degrada a todas las demás peticiones del proceso.

// ❌ Lo peor: I/O bloqueante en el pool común
urls.parallelStream().map(this::llamadaHttp).toList();   // secuestra el commonPool

// ✅ Para I/O: hilos virtuales, un hilo por tarea
try (var ex = Executors.newVirtualThreadPerTaskExecutor()) {
    var futuros = urls.stream().map(u -> ex.submit(() -> llamadaHttp(u))).toList();
    var res = futuros.stream().map(Future::resultNow).toList();
}

// ✅ Para CPU con muchos datos, midiendo antes y después
long primos = LongStream.rangeClosed(2, 50_000_000).parallel().filter(this::esPrimo).count();

// Si de verdad necesitas paralelo con un pool propio (truco poco conocido):
var pool = new ForkJoinPool(4);
pool.submit(() -> datos.parallelStream().map(this::calcular).toList()).join();

Trampa: «¿y si hago forEach en paralelo y acumulo en una lista?». forEach en paralelo no garantiza orden y añadir a un ArrayList desde varios hilos corrompe la estructura. Para acumular está collect, que sí está diseñado para partir y combinar. Y si necesitas orden, forEachOrdered, que además elimina buena parte de la ventaja del paralelismo.

Porque los requisitos son distintos. Para primitivos usa dual-pivot quicksort: es O(n log n) medio, ordena en el sitio sin memoria extra y la estabilidad no importa (dos enteros iguales son indistinguibles). Para objetos usa TimSort, que es estable —conserva el orden relativo de los elementos equivalentes, algo que sí se nota cuando ordenas por un campo y luego por otro— y aprovecha las secuencias ya ordenadas, muy frecuentes en datos reales, a costa de memoria auxiliar.

// Estabilidad: ordenar por dos criterios encadenando (mismo resultado que un comparador compuesto)
pedidos.sort(comparing(Pedido::cliente));           // primero por cliente
pedidos.sort(comparing(Pedido::fecha));             // luego por fecha; dentro de cada
                                                    // fecha se conserva el orden por cliente

// Mejor y más explícito: un solo comparador
pedidos.sort(comparing(Pedido::fecha).thenComparing(Pedido::cliente).reversed());

// Cuidado con los null
pedidos.sort(comparing(Pedido::fechaEnvio, nullsLast(naturalOrder())));

Detalle que sorprende y que da puntos: un Comparator inconsistente —que no cumple que compare(a,b) y compare(b,a) tengan signos opuestos, o que no sea transitivo— hace que TimSort lance IllegalArgumentException: Comparison method violates its general contract!. La causa habitual es restar enteros (a.id() - b.id()) y desbordar, o comparar por un campo mutable que cambia durante la ordenación. Usa Integer.compare en lugar de la resta.

Trampa: ordenar en Java lo que podía ordenar la base de datos. Si los datos vienen de una consulta, el ORDER BY con un índice adecuado es más rápido, no consume memoria del proceso y permite paginar. Ordenar en memoria solo tiene sentido si los datos ya están ahí por otro motivo.

Un proceso tiene su propio espacio de memoria virtual aislado por el sistema operativo; un hilo es una unidad de ejecución dentro de un proceso que comparte el heap con los demás hilos y tiene su propia pila y su propio contador de programa.

Por qué importa: compartir memoria es lo que hace la comunicación entre hilos baratísima y, a la vez, lo que genera toda la categoría de problemas de concurrencia. Y el coste no es simétrico: crear un proceso cuesta milisegundos y megabytes; crear un hilo de plataforma cuesta unas decenas de microsegundos y en torno a 1 MB de pila reservada. Ese último número es el que explica por qué no puedes tener cien mil hilos de plataforma y por qué se inventaron los hilos virtuales, cuya pila vive en el heap y crece según necesita (empieza con unos cientos de bytes).

Trampa: la repregunta es «¿cuántos hilos tiene tu aplicación Spring Boot?». La respuesta con criterio: Tomcat trae 200 hilos de trabajo por defecto, más los del pool de conexiones, los de las tareas programadas, los del cliente HTTP y los del recolector de basura. Es fácil que una aplicación «sencilla» tenga 250 hilos, y en un contenedor con 1 GB de memoria eso ya es un consumo nativo considerable que no aparece en el heap.

Seis, definidos en Thread.State, y saber distinguir los tres de espera es lo que sirve para leer un volcado de hilos:

NEW            creado pero sin start()
RUNNABLE       ejecutándose o listo para ejecutarse (¡también si está en I/O!)
BLOCKED        esperando para entrar en un bloque synchronized (esperando un monitor)
WAITING        esperando indefinidamente: wait(), join(), LockSupport.park()
TIMED_WAITING  esperando con plazo: sleep(ms), wait(ms), join(ms), tryLock(t)
TERMINATED     ha terminado (normal o por excepción)

El detalle que casi nadie sabe y que da muchos puntos: un hilo bloqueado en una lectura de socket o de fichero aparece como RUNNABLE, no como BLOCKED, porque la JVM no tiene forma de saber que el sistema operativo lo ha suspendido. Así que en un thread dump, cien hilos RUNNABLE con SocketInputStream.read en la cima de la pila no significan cien hilos consumiendo CPU: significan cien hilos esperando a un servicio remoto que no responde.

Cómo se usa esto en la práctica: jcmd <pid> Thread.print tres veces con cinco segundos de separación. Si los mismos hilos están en el mismo sitio, tienes un bloqueo; si están en BLOCKED apuntando a un monitor común, tienes contención; si cambian sin parar y están RUNNABLE en tu código, tienes un problema de CPU.

Trampa: «¿y Thread.stop()?». Está eliminado (lanzaba una excepción asíncrona en cualquier punto y dejaba invariantes rotos). La forma correcta de parar un hilo es cooperativa: interrupt() más comprobar Thread.currentThread().isInterrupted() y propagar la InterruptedException en lugar de tragársela.

synchronized es del lenguaje: la JVM adquiere y libera el monitor por ti, así que es imposible olvidarse de liberar. ReentrantLock es una clase de la biblioteca: más potente y más peligrosa, porque liberar es tu responsabilidad.

// ReentrantLock: el finally NO es opcional
private final ReentrantLock lock = new ReentrantLock();
void transferir(Cuenta destino, BigDecimal importe) {
    if (!lock.tryLock(5, TimeUnit.SECONDS)) {      // no espero para siempre
        throw new RecursoOcupado("cuenta " + id);
    }
    try { saldo = saldo.subtract(importe); destino.ingresar(importe); }
    finally { lock.unlock(); }                     // ← si falta esto, deadlock permanente
}

// ReadWriteLock: muchas lecturas, pocas escrituras
private final var rw = new ReentrantReadWriteLock();
Config leer()  { rw.readLock().lock();  try { return config; } finally { rw.readLock().unlock(); } }
void escribir(Config c) { rw.writeLock().lock(); try { config = c; } finally { rw.writeLock().unlock(); } }
// Aunque para este caso concreto, un campo volatile con objeto inmutable es mejor.

La regla práctica: synchronized por defecto, y ReentrantLock solo cuando necesites timeout, interrupción, equidad o varias condiciones. Y antes de cualquiera de los dos, pregúntate si puedes eliminar el estado compartido, usar un atómico o una colección concurrente: es la mejor optimización de concurrencia que existe.

Trampa: los dos son reentrantes (el mismo hilo puede volver a adquirir el cerrojo que ya tiene). Si te preguntan por qué eso es necesario, la respuesta es que sin reentrada un método synchronized que llama a otro synchronized de la misma instancia se bloquearía consigo mismo.

Dos cosas: visibilidad —una escritura se hace visible a los demás hilos inmediatamente, sin quedarse en la caché del procesador o en un registro— y ordenación —el compilador y la CPU no pueden reordenar accesos alrededor de un acceso volátil—. Lo que no garantiza es atomicidad de las operaciones compuestas.

// ✅ Caso de uso canónico: bandera de parada
private volatile boolean parar = false;
public void run() { while (!parar) { trabajar(); } }   // sin volatile, el JIT puede
public void detener() { parar = true; }                // cachear la condición y no salir NUNCA

// ❌ Lo que NO arregla: contador++ son tres operaciones (leer, sumar, escribir)
private volatile int n;
void incrementar() { n++; }        // sigue siendo una carrera → usa AtomicInteger

// ✅ Publicación segura de un objeto inmutable (patrón muy útil)
private volatile Config config;                   // se lee mucho, se escribe rarísimo
public Config get() { return config; }            // lectura sin cerrojos
public void recargar(Config nueva) { config = nueva; }  // sustitución atómica de referencia

Cómo funciona por debajo: una escritura volátil inserta una barrera de memoria (store fence) que vuelca las escrituras anteriores; una lectura volátil inserta una barrera de lectura. Eso crea una relación happens-before entre la escritura y cualquier lectura posterior, y con ella la garantía de que también ves todo lo que el otro hilo escribió antes de la escritura volátil.

Trampa: el ejemplo del double-checked locking. El campo de la instancia perezosa debe ser volatile; sin él, otro hilo puede ver la referencia ya asignada pero el objeto a medio construir. Y si te lo preguntan, la respuesta moderna es: no implementes double-checked locking, usa un enum, un holder estático o deja que el contenedor de Spring gestione el ciclo de vida.

Es la relación del modelo de memoria de Java que define cuándo un hilo tiene garantizado ver lo que escribió otro. Sin una relación happens-before entre dos accesos, el compilador, la CPU y las cachés tienen libertad para reordenar y para no propagar, y no hay ninguna garantía sobre lo que verás.

Las reglas que crean happens-before (las que hay que saber nombrar):

1. Orden del programa: dentro de un mismo hilo, todo va en orden.
2. Monitor: liberar un cerrojo happens-before adquirirlo el siguiente hilo.
3. Volatile: escribir un volatile happens-before leerlo.
4. Thread.start(): todo lo anterior al start() es visible al hilo nuevo.
5. Thread.join(): todo lo que hizo el hilo es visible tras el join().
6. Campos final: inicializados en el constructor, visibles sin sincronizar
   (siempre que el constructor no filtre this).
7. Transitividad: si A hb B y B hb C, entonces A hb C.

Además, todas las utilidades de java.util.concurrent lo garantizan:
poner en una BlockingQueue hb sacarlo, submit() hb ejecutar la tarea,
completar un Future hb leer su resultado, contar en un CountDownLatch hb await().

Por qué importa: es la razón por la que este código, que parece obviamente correcto, puede no terminar nunca o imprimir 0:

// Sin ninguna sincronización: no hay happens-before
int dato = 0;
boolean listo = false;

// Hilo A
dato = 42;
listo = true;

// Hilo B
while (!listo) { }            // puede no salir nunca (el JIT saca la lectura del bucle)
System.out.println(dato);      // y si sale, puede imprimir 0 (reordenación)

// Arreglado: volatile en 'listo' crea la relación y arrastra también a 'dato'
// (por la regla 3 + la regla 7).

Trampa: «entonces con synchronized en el setter basta, ¿no?». No: hace falta sincronizar las dos partes, la escritura y la lectura, sobre el mismo cerrojo. Un setter sincronizado y un getter sin sincronizar no crean ninguna relación y el bug es exactamente igual de real, solo más difícil de reproducir.

Una condición de carrera aparece cuando el resultado depende del entrelazado de los hilos. El caso canónico es leer-modificar-escribir sin atomicidad, y el ejemplo con más consecuencias reales es una comprobación de stock:

// ❌ El bug: dos hilos pueden pasar la comprobación con stock = 1
class Inventario {
    private int stock = 1;
    boolean reservar() {
        if (stock > 0) {          // hilo A lee 1 ─┐
            stock--;               // hilo B lee 1 ─┘ los dos reservan → stock = -1
            return true;
        }
        return false;
    }
}

// ✅ Solución 1: sincronizar la operación completa (no cada paso)
synchronized boolean reservar() {
    if (stock > 0) { stock--; return true; }
    return false;
}

// ✅ Solución 2: un atómico con CAS en bucle (sin cerrojos)
private final AtomicInteger stock = new AtomicInteger(1);
boolean reservar() {
    int actual;
    do {
        actual = stock.get();
        if (actual == 0) return false;
    } while (!stock.compareAndSet(actual, actual - 1));   // reintenta si otro se coló
    return true;
}
// O más corto y con la misma garantía:
// return stock.getAndUpdate(v -> v > 0 ? v - 1 : v) > 0;

// ✅ Solución 3 (la real en una aplicación con base de datos): que lo garantice el motor
// UPDATE producto SET stock = stock - 1 WHERE id = ? AND stock > 0;
// Si filas_afectadas == 0 → no había stock. Atómico, y funciona con N instancias.

La tercera solución es la que separa una respuesta académica de una respuesta de producción: en un sistema con varias instancias detrás de un balanceador, synchronized y AtomicInteger no sirven de nada, porque cada JVM tiene su propio cerrojo y su propio contador. La exclusión tiene que estar donde está el estado compartido: la base de datos.

Trampa: te pueden pedir el test que lo demuestra. Es esta receta: N hilos, un CountDownLatch para arrancarlos a la vez, y comprobar el invariante al final. Sin el latch, los hilos se arrancan escalonados y la carrera no se reproduce.

Compare-And-Swap es una instrucción del procesador que, de forma atómica, compara el valor de una posición de memoria con el esperado y, si coincide, lo cambia. Las clases de java.util.concurrent.atomic se construyen sobre ella: consiguen atomicidad sin cerrojos, con un bucle de reintentos (optimistic locking en memoria).

var contador = new AtomicLong();
contador.incrementAndGet();                          // atómico, sin bloquear
contador.updateAndGet(v -> Math.min(v + 1, MAX));    // función arbitraria, con reintento
contador.accumulateAndGet(5, Long::sum);

var referencia = new AtomicReference<Config>(inicial);
referencia.compareAndSet(esperada, nueva);           // solo si nadie la cambió

// Alta contención: LongAdder reparte el contador en celdas por hilo
var peticiones = new LongAdder();
peticiones.increment();                              // escala mucho mejor con 64 hilos
long total = peticiones.sum();                        // el coste se paga al leer

Cuándo elegir cada uno: AtomicLong si lees el valor a menudo; LongAdder si escribes muchísimo y lees poco (métricas, contadores de peticiones), porque evita que todos los hilos peleen por la misma línea de caché. Y AtomicReference para sustituir de forma atómica un objeto inmutable completo, que es un patrón elegantísimo para configuración en caliente.

El límite de CAS es el problema ABA y la degradación con contención muy alta: si mil hilos reintentan sobre la misma variable, se quema CPU en reintentos y un cerrojo puede acabar siendo más eficiente. Para ABA existe AtomicStampedReference, que añade un contador de versión.

Trampa: «¿es lo mismo que volatile?». No. volatile da visibilidad y ordenación pero no atomicidad; los atómicos dan las tres. Un AtomicInteger es, conceptualmente, un int volatile más operaciones CAS.

Dos o más hilos bloqueados para siempre, cada uno esperando un recurso que retiene otro. Hacen falta cuatro condiciones simultáneas (Coffman): exclusión mutua, retener y esperar, no preferencia (no se pueden quitar los cerrojos) y espera circular. Romper cualquiera de las cuatro elimina el problema.

// Provocarlo: dos cerrojos adquiridos en orden opuesto
void transferir(Cuenta origen, Cuenta destino, BigDecimal importe) {
    synchronized (origen) {
        synchronized (destino) { origen.restar(importe); destino.sumar(importe); }
    }
}
// transferir(A, B) en un hilo y transferir(B, A) en otro → deadlock

// ✅ Solución 1: ORDEN GLOBAL de adquisición (la más usada)
void transferir(Cuenta a, Cuenta b, BigDecimal importe) {
    Cuenta primero = a.id().compareTo(b.id()) < 0 ? a : b;
    Cuenta segundo = primero == a ? b : a;
    synchronized (primero) { synchronized (segundo) { ... } }
}

// ✅ Solución 2: tryLock con timeout y reintento (rompe "retener y esperar")
if (a.lock.tryLock(1, SECONDS)) {
    try {
        if (b.lock.tryLock(1, SECONDS)) {
            try { ... } finally { b.lock.unlock(); }
        } else { throw new NoSePudoAdquirir(); }   // libera y reintenta más tarde
    } finally { a.lock.unlock(); }
}

// ✅ Solución 3: eliminar el problema. Un único cerrojo de grano grueso, o mejor,
// una sola transacción de base de datos con las filas bloqueadas en orden de id.

# Detectarlo en producción: la JVM lo dice explícitamente
jcmd <pid> Thread.print | grep -A 30 "Found one Java-level deadlock"
# También: jstack <pid>, o VisualVM / JMC, que lo marcan en rojo.
# En un contenedor: kubectl exec -it pod -- jcmd 1 Thread.print

Un deadlock clásico de aplicaciones Spring que merece la pena mencionar: agotamiento del pool de conexiones. Un método @Transactional que, con la conexión ya tomada, llama a otro método que pide otra conexión del mismo pool. Con maximumPoolSize = 10 y diez peticiones simultáneas, las diez conexiones están retenidas y las diez esperan una undécima que no existe. No aparece como deadlock en el volcado de hilos: aparece como timeout de HikariCP, y eso lo hace más difícil de diagnosticar.

Trampa: te pueden preguntar si la JVM puede resolver un deadlock automáticamente. No: solo lo detecta y lo informa. La recuperación es reiniciar el proceso o haber diseñado con timeouts, que es la única defensa real en un sistema distribuido.

En los tres casos no se avanza, pero por motivos distintos, y la diferencia importa porque se diagnostican de forma opuesta:

Las soluciones: para livelock, introducir aleatoriedad (retroceso exponencial con jitter) y un límite de reintentos; es exactamente lo mismo que se hace con los reintentos entre microservicios. Para starvation, cerrojos equitativos, colas FIFO, envejecimiento de prioridades y separar el trabajo en pools distintos (bulkhead) para que las tareas largas no ahoguen a las cortas.

Trampa: el livelock distribuido más frecuente es la «tormenta de reintentos»: un servicio se degrada, todos los clientes reintentan al mismo tiempo, la carga aumenta, se degrada más. Se ataca con jitter, circuit breaker y presupuesto de reintentos. Nombrar esa conexión entre concurrencia y sistemas distribuidos causa muy buena impresión.

ExecutorService desacopla la tarea del hilo: tú envías trabajo y el pool decide cómo ejecutarlo. Los fabricados por Executors son atajos, y dos de ellos son trampas conocidas.

Executors.newFixedThreadPool(8);        // N hilos + LinkedBlockingQueue SIN LÍMITE
                                        // ⚠ la cola crece hasta el OutOfMemoryError
Executors.newCachedThreadPool();        // hilos ilimitados, se reciclan a los 60 s
                                        // ⚠ con carga alta crea miles de hilos y muere
Executors.newSingleThreadExecutor();    // serializa las tareas: útil para orden garantizado
Executors.newScheduledThreadPool(2);    // tareas periódicas o con retardo
Executors.newVirtualThreadPerTaskExecutor();  // Java 21: un hilo virtual por tarea

// ✅ En producción, casi siempre a mano: control total y cola ACOTADA
var ex = new ThreadPoolExecutor(
        8, 16,                                   // core, máximo
        60L, TimeUnit.SECONDS,                   // tiempo de vida de los hilos extra
        new ArrayBlockingQueue<>(1000),          // cola acotada = contrapresión
        new CustomizableThreadFactory("pedidos-"),// nombres útiles en los thread dumps
        new ThreadPoolExecutor.CallerRunsPolicy());// política de rechazo explícita

// Apagado ordenado: el patrón completo
ex.shutdown();                                    // no acepta más, termina lo pendiente
if (!ex.awaitTermination(30, TimeUnit.SECONDS)) {
    ex.shutdownNow();                             // interrumpe lo que queda
}

Las cuatro políticas de rechazo, que es una pregunta frecuente: AbortPolicy (por defecto, lanza RejectedExecutionException), CallerRunsPolicy (la ejecuta el hilo que la envió, lo que aplica contrapresión de forma natural y suele ser la mejor opción en un servidor), DiscardPolicy y DiscardOldestPolicy (tirar trabajo silenciosamente: peligrosísimo si la tarea importa).

Trampa: con ThreadPoolExecutor, los hilos por encima de corePoolSize solo se crean cuando la cola está llena. Si pones una cola ilimitada, el máximo nunca se alcanza y tu pool de «8 a 64 hilos» es en realidad un pool de 8. Es uno de los malentendidos más extendidos.

Depende de si la tarea es de CPU o de espera, y en 2026 hay que añadir un tercer caso: con hilos virtuales no se dimensionan hilos, se limita el recurso escaso real.

Tareas de CPU:      hilos ≈ núcleos disponibles (o núcleos + 1)
                    Más hilos solo añaden cambios de contexto.
                    En contenedor: Runtime.availableProcessors() ya respeta los
                    límites de CPU del cgroup en JVM modernas.

Tareas de espera:   hilos ≈ núcleos × (1 + tiempo_espera / tiempo_cpu)
                    Ejemplo: 4 núcleos, 90 ms esperando la BD, 10 ms de CPU
                             4 × (1 + 90/10) = 40 hilos

Comprobación por la ley de Little:
                    concurrencia = throughput objetivo × latencia media
                    500 req/s × 0,2 s = 100 peticiones en vuelo

Con hilos virtuales (Java 21+):
                    No limites hilos. Limita lo que de verdad es escaso:
                    · pool de conexiones a la BD (HikariCP)
                    · semáforo para la cuota de una API externa
                    · bulkhead de Resilience4j por dependencia

La forma de decirlo que suena a experiencia: «la fórmula da un punto de partida, pero el número real sale de medir. Subo el pool y mido latencia p95 y throughput; llega un punto en que el throughput deja de subir y la latencia empieza a empeorar: ahí está el óptimo, y normalmente el cuello no es la CPU sino las conexiones a la base de datos.»

Trampa: el error clásico es poner un pool enorme «para aguantar picos». Doscientos hilos peleando por diez conexiones de base de datos no dan más rendimiento: dan más memoria consumida, más cambios de contexto y colas invisibles con latencias peores. El pool de hilos nunca debe ser mucho mayor que el recurso escaso al que espera.

Es la API para composición asíncrona: permite encadenar y combinar tareas sin bloquear ningún hilo hasta el final. Lo que se pregunta siempre son los tres puntos donde la gente se equivoca.

// Composición: tres llamadas en paralelo y combinación
var cliente  = supplyAsync(() -> clienteApi.buscar(id), ex);
var pedidos  = supplyAsync(() -> pedidosApi.de(id), ex);
var puntos   = supplyAsync(() -> fidelidadApi.puntos(id), ex);

var ficha = cliente
        .thenCombine(pedidos, FichaCliente::new)         // combinar dos
        .thenCombine(puntos,  FichaCliente::conPuntos)
        .orTimeout(2, TimeUnit.SECONDS)                  // límite global
        .exceptionally(e -> FichaCliente.degradada(id))   // fallback
        .join();

// thenApply vs thenCompose: el mismo par map/flatMap de siempre
CompletableFuture<CompletableFuture<Pedido>> mal = f.thenApply(this::cargarAsync);
CompletableFuture<Pedido> bien = f.thenCompose(this::cargarAsync);

// Manejo de errores: los tres métodos y sus diferencias
f.exceptionally(e -> valorPorDefecto);          // solo en error, devuelve valor
f.handle((v, e) -> e != null ? defecto : v);    // siempre, ve valor y error
f.whenComplete((v, e) -> log.info("fin"));      // siempre, NO transforma el resultado

// ⚠ El error silencioso número uno: no consumir el resultado
supplyAsync(this::algoQuePuedeFallar);   // si lanza, NADIE se enterará nunca

El executor por defecto es el ForkJoinPool.commonPool(), compartido por toda la JVM y con núcleos - 1 hilos. Usarlo para I/O es un error grave: bloqueas un recurso global. Pasa siempre un executor propio a los métodos *Async. Y ojo con el detalle fino: los métodos sin Async pueden ejecutarse en el hilo que completó el futuro anterior o en el hilo que llama, según los tiempos; si te importa dónde corre la continuación, usa la variante Async con executor explícito.

join() frente a get(): los dos bloquean, pero join lanza la CompletionException no comprobada y get obliga a capturar InterruptedException y ExecutionException. En código de composición se usa join por comodidad; con get(timeout) tienes plazo, que es lo importante.

Trampa: con hilos virtuales, muchísimo de esto se simplifica. Si la razón por la que usabas CompletableFuture era «no bloquear un hilo de plataforma», en Java 21 puedes escribir código secuencial bloqueante dentro de hilos virtuales, o usar concurrencia estructurada, y leerlo mucho mejor. CompletableFuture sigue siendo útil para composición y para APIs que ya lo devuelven.

Es una variable con una copia por hilo: cada hilo ve su propio valor. Se usa para propagar contexto sin pasarlo por parámetro, y por eso está en el corazón de muchas cosas de Spring: SecurityContextHolder, TransactionSynchronizationManager, el MDC de los logs y RequestContextHolder.

private static final ThreadLocal<String> TRACE = new ThreadLocal<>();

// ✅ El patrón obligatorio: try/finally con remove()
void manejar(Peticion p) {
    TRACE.set(p.traceId());
    try { procesar(p); }
    finally { TRACE.remove(); }     // ← sin esto, fuga garantizada en un pool
}

La fuga ocurre porque el valor se guarda en un mapa dentro del objeto Thread. En un servidor los hilos se reutilizan indefinidamente desde un pool, así que si no llamas a remove(), el valor sobrevive a la petición y queda retenido para siempre: si es un objeto grande (una entidad, un contexto con la sesión entera), multiplica por el número de hilos del pool y tienes megabytes retenidos. Y hay un segundo efecto, peor que la memoria: fuga de información, porque la petición siguiente que caiga en ese hilo verá el contexto del usuario anterior.

En 2026 hay que mencionar la alternativa: ScopedValue (Java 21+ en incubación, estabilizado en versiones posteriores), diseñado precisamente para esto. Es inmutable, tiene un ámbito delimitado y explícito, se limpia solo al salir del bloque y se hereda correctamente en concurrencia estructurada.

// ScopedValue: sin fugas por construcción
private static final ScopedValue<String> TRACE = ScopedValue.newInstance();

ScopedValue.where(TRACE, p.traceId()).run(() -> procesar(p));
// Dentro: TRACE.get(); fuera: no existe. No hay remove() que olvidar.

Trampa: con hilos virtuales, ThreadLocal funciona pero escala mal: si tienes un millón de hilos virtuales, tienes un millón de copias del valor. Es otro motivo por el que ScopedValue existe. Y InheritableThreadLocal con pools es directamente una fuente de bugs, porque el hilo hijo hereda el valor del hilo que lo creó, no del que envía la tarea.

Hilos gestionados por la JVM en lugar de por el sistema operativo. Son baratísimos (microsegundos y cientos de bytes) y, cuando se bloquean en una operación de I/O, la JVM los desmonta del hilo portador y deja ese hilo del sistema libre para otra tarea. El resultado: el modelo «un hilo por petición», que es el más sencillo de leer y de depurar, escala a cientos de miles de tareas concurrentes.

// Spring Boot 3.5: una línea y todo el servidor pasa a hilos virtuales
// spring.threads.virtual.enabled=true

// A mano
try (var ex = Executors.newVirtualThreadPerTaskExecutor()) {
    for (var id : ids) ex.submit(() -> procesar(id));   // 100.000 tareas sin problema
}   // close() espera a que terminen todas

// Código bloqueante, secuencial y legible... y escalable
var cliente = clienteApi.buscar(id);      // bloquea el hilo VIRTUAL, no el del SO
var pedidos = pedidosApi.de(id);          // el portador atendió otras tareas mientras

Qué cambian en la práctica: eliminan el dilema entre «legible pero no escala» (hilos de plataforma) y «escala pero es un infierno de depurar» (programación reactiva). Un stack trace de un hilo virtual es un stack trace normal y completo, y el depurador funciona; con Reactor no.

Cuándo NO ayudan, que es lo que de verdad quieren oír:

• Trabajo de CPU. No hay magia: si el cuello es el procesador, un millón de hilos virtuales no crean núcleos.
• El cuello está detrás. Si tienes 10 conexiones a PostgreSQL, tener 50.000 hilos virtuales solo consigue que 49.990 esperen en el pool. El límite se mueve, no desaparece.
• Pinning. Un hilo virtual bloqueado dentro de un bloque synchronized o en una llamada nativa (JNI) no podía desmontarse y ocupaba el portador. Con pocos portadores, eso puede paralizar el sistema. En Java 24 se eliminó el pinning por synchronized, pero si trabajas con 21 hay que sustituir synchronized por ReentrantLock en las secciones que hacen I/O.
• ThreadLocal masivo y librerías que cachean por hilo: con un millón de hilos, un millón de copias.
• No agrupes hilos virtuales. Un pool de hilos virtuales es un contrasentido: son tan baratos que crear uno por tarea es lo correcto.

Trampa: «entonces ya no hace falta programación reactiva». Casi: sigue teniendo sentido cuando necesitas contrapresión real de extremo a extremo, flujos de streaming (Server-Sent Events, WebSocket con muchísimas conexiones) u operadores de composición complejos. Pero para una API REST que llama a una base de datos y a dos servicios, hilos virtuales con código bloqueante es hoy la respuesta razonable.

Un modelo en el que las tareas concurrentes tienen un ámbito léxico: se lanzan y se esperan dentro del mismo bloque, y ese bloque no termina hasta que todas han acabado, se han cancelado o han fallado. Elimina las tres plagas del ExecutorService suelto: tareas huérfanas, fugas de cancelación y errores que se pierden.

// Java 21+ (API en evolución; en 25 es StructuredTaskScope.open())
// Política "todas o ninguna": si una falla, las demás se cancelan
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var cliente = scope.fork(() -> clienteApi.buscar(id));
    var pedidos = scope.fork(() -> pedidosApi.de(id));
    var puntos  = scope.fork(() -> fidelidadApi.puntos(id));

    scope.joinUntil(Instant.now().plusSeconds(2));   // espera con plazo
    scope.throwIfFailed(e -> new FichaNoDisponible(id, e));

    return new Ficha(cliente.get(), pedidos.get(), puntos.get());
}   // al salir del try, NINGUNA tarea sigue viva. Garantizado.

// Política "el primero que responda gana" (útil para réplicas o mirrors)
try (var scope = new StructuredTaskScope.ShutdownOnSuccess<Precio>()) {
    scope.fork(() -> proveedorA.precio(sku));
    scope.fork(() -> proveedorB.precio(sku));
    scope.join();
    return scope.result();                            // el otro se cancela solo
}

Las ventajas que hay que nombrar: la relación padre-hijo es explícita, así que la cancelación se propaga hacia abajo automáticamente; los errores se agregan y no se pierden; el stack trace incluye el contexto del padre, lo que hace que depurar concurrencia se parezca por fin a depurar código secuencial; y no puedes «olvidarte» de esperar una tarea, porque el try no te deja salir.

Trampa: si te preguntan la diferencia con CompletableFuture.allOf, la respuesta es la cancelación y la vida de las tareas. Con allOf, si una falla, las otras siguen ejecutándose consumiendo recursos y nadie las espera; con concurrencia estructurada, al salir del ámbito no queda nada vivo.

Sobre el objeto Class de la clase: MiClase.class. Un método de instancia synchronized sincroniza sobre this. Son dos cerrojos distintos, así que un método estático sincronizado y uno de instancia sincronizado pueden ejecutarse a la vez, y esa es la fuente de un bug sutil si comparten estado.

class Contador {
    private static int global;
    private int local;

    static synchronized void incGlobal() { global++; }   // cerrojo: Contador.class
    synchronized void incLocal()         { local++;  }   // cerrojo: this

    // ❌ El bug: este método toca estado estático con el cerrojo de la instancia
    synchronized void incGlobalMal() { global++; }
    // Dos instancias distintas → dos cerrojos distintos → carrera sobre 'global'

    // ✅ Bloques explícitos, que es lo recomendable: el cerrojo se ve
    private static final Object CERROJO_GLOBAL = new Object();
    void incGlobalBien() { synchronized (CERROJO_GLOBAL) { global++; } }
}

Buenas prácticas asociadas: sincroniza sobre un objeto privado y dedicado, no sobre this (porque cualquiera desde fuera puede sincronizar sobre tu instancia y bloquearte) y jamás sobre un objeto que pueda cambiar de referencia, ni sobre una cadena internada, ni sobre un envoltorio numérico del rango de la caché de Integer, porque podrías estar compartiendo cerrojo con código completamente ajeno.

Trampa: en un bean singleton de Spring, sincronizar sobre this parece razonable porque hay una sola instancia… hasta que alguien cambia el scope a prototype o el bean se envuelve en un proxy y de repente hay dos objetos. Un cerrojo privado y estático no tiene ese problema.

Es el patrón para desacoplar quien genera trabajo de quien lo procesa, con la cola actuando de amortiguador. La versión correcta usa una BlockingQueue, que hace toda la sincronización por ti.

// Cola ACOTADA: es la decisión de diseño importante
private final BlockingQueue<Pedido> cola = new ArrayBlockingQueue<>(1000);
private static final Pedido FIN = new Pedido("__FIN__");   // píldora envenenada

// Productor
void producir(Pedido p) throws InterruptedException {
    cola.put(p);                     // BLOQUEA si está llena → contrapresión
    // alternativa con plazo: if (!cola.offer(p, 2, SECONDS)) rechazar(p);  → 503
}

// Consumidores (N hilos)
void consumir() {
    try {
        while (true) {
            var p = cola.take();     // bloquea si está vacía
            if (p == FIN) { cola.put(FIN); break; }   // reinyecta para los demás
            procesar(p);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();          // restaurar la bandera: importante
    }
}

Por qué acotada: una cola ilimitada convierte un problema de rendimiento en una caída. Si el consumidor es más lento que el productor —y tarde o temprano lo será—, la cola crece hasta agotar el heap y el proceso muere con OutOfMemoryError, perdiendo todo el trabajo acumulado. Con una cola acotada, el productor se frena (put bloquea) o rechaza explícitamente (offer con plazo devuelve false y respondes 503 con Retry-After). Eso es contrapresión: el sistema se degrada de forma controlada en lugar de romperse.

La versión de producción de esto no es código propio: es una cola real (Kafka, RabbitMQ, SQS) para que el trabajo sobreviva a un reinicio del proceso. Decirlo demuestra que distingues un patrón de concurrencia de una arquitectura duradera.

Trampa: tragarse la InterruptedException sin restaurar la bandera de interrupción es un error clásico: el hilo deja de responder a la cancelación y el apagado ordenado de la aplicación se queda esperando treinta segundos hasta que Kubernetes lo mata con SIGKILL.

Dos grandes bloques: el heap, que gestiona el recolector de basura, y la memoria nativa (todo lo demás), que no aparece en -Xmx y es la causa de la mitad de los OOMKilled en contenedores.

HEAP (-Xms / -Xmx) ─ gestionado por el GC
  · Young generation: Eden + dos Survivor. Casi todos los objetos mueren aquí (minor GC).
  · Old generation (tenured): los que sobreviven varias colecciones.
  · G1 no usa zonas contiguas, sino regiones de 1-32 MB etiquetadas dinámicamente.

FUERA DEL HEAP ─ memoria nativa, NO la limita -Xmx
  · Metaspace: metadatos de clases. Crece dinámicamente (limita con -XX:MaxMetaspaceSize).
  · Code cache: código compilado por el JIT (~240 MB por defecto).
  · Pilas de hilos: ~1 MB por hilo de plataforma (-Xss). 250 hilos = 250 MB.
  · Direct buffers / mapped: ByteBuffer.allocateDirect, NIO, Netty (-XX:MaxDirectMemorySize).
  · Estructuras internas del GC, JIT, JNI y el propio proceso.

Regla práctica en contenedores:
  memoria del contenedor ≈ heap + metaspace + code cache + (hilos × Xss) + direct + ~100 MB
  Por eso -Xmx igual al límite del contenedor = OOMKilled seguro.
  Usa -XX:MaxRAMPercentage=70 y deja margen.

Y cada hilo tiene además su propia pila (marcos de método, variables locales y referencias) y su contador de programa. Los objetos siempre viven en el heap; en la pila solo hay primitivos locales y referencias —salvo cuando el JIT aplica escape analysis y decide que un objeto que no se escapa del método puede ir a la pila o desaparecer del todo—.

Trampa: te pueden preguntar por qué el contenedor muere con 1 GB de límite si -Xmx es 900 MB y el heap solo llega a 400 MB. La respuesta: metaspace, pilas de 250 hilos, code cache y buffers directos. La herramienta para verlo es Native Memory Tracking (-XX:NativeMemoryTracking=summary y jcmd <pid> VM.native_memory summary).

El mensaje después de los dos puntos es el diagnóstico, y saberlos distingue a quien ha estado de guardia de quien no:

# Configuración que deberías tener SIEMPRE en producción
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/dumps/
-XX:+ExitOnOutOfMemoryError          # que muera y lo reinicie el orquestador
-XX:MaxRAMPercentage=70              # en contenedor, en lugar de -Xmx fijo

# Diagnóstico en caliente, sin reiniciar
jcmd <pid> GC.heap_info
jcmd <pid> GC.class_histogram | head -30      # qué clases ocupan más
jcmd <pid> GC.heap_dump /tmp/dump.hprof       # ojo: pausa el proceso
jcmd <pid> VM.native_memory summary           # con NativeMemoryTracking activado

Trampa: OutOfMemoryError es un Error, no una Exception, y no se debe capturar: la JVM está en un estado en el que cualquier operación puede fallar, incluido el propio log. Lo correcto es morir, dejar el heap dump y que el orquestador levante una instancia nueva.

Cuatro relevantes en 2026, y la elección se hace por el objetivo (latencia o rendimiento bruto) y por el tamaño del heap, no por cuál es más moderno.

# G1 con objetivo de pausa (por defecto desde Java 9)
-XX:+UseG1GC -XX:MaxGCPauseMillis=100

# ZGC generacional (recomendado desde Java 21; en 23+ es el modo por defecto de ZGC)
-XX:+UseZGC -XX:+ZGenerational

# Lo que SIEMPRE hay que hacer antes de tocar el GC: mirar los datos
-Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags:filecount=5,filesize=10M
# Y analizarlo con GCViewer o gceasy.io: frecuencia, duración y si el heap
# después de un full GC baja o se queda alto (eso último es una fuga).

La respuesta que impresiona: «no cambiaría el GC como primera medida. En la práctica, el 90 % de los problemas que se achacan al recolector son en realidad demasiada basura generada o una fuga. Primero mediría con los logs de GC y un perfil de asignación; solo si el problema es de verdad la duración de las pausas y no puedo reducir la asignación, cambiaría a ZGC.»

Trampa: la ley fundamental del GC es que los objetos que mueren jóvenes son gratis. Un minor GC copia solo lo que sobrevive, así que crear muchos objetos de vida cortísima cuesta muy poco. Lo caro es que sobrevivan al Eden y promocionen a la generación antigua. Por eso una caché mal dimensionada duele mucho más que un bucle que crea objetos temporales.

Primero estabilizar, después diagnosticar. Y el orden importa porque el objetivo inicial no es entender: es dejar de perder dinero.

1. Contener (minutos 0-5). ¿Hay un despliegue reciente? Rollback. ¿Hay más instancias posibles? Escalar horizontalmente para repartir. Quitar del balanceador la instancia enferma pero sin matarla, que es la que vas a examinar.
2. Confirmar que es Java. top -H -p <pid> para ver qué hilos consumen. Si la CPU está en hilos del GC, es un problema de memoria disfrazado de CPU.
3. Identificar el hilo culpable. Toma el ID del hilo de top, pásalo a hexadecimal y búscalo en el volcado: ahí tienes la pila exacta del código que está quemando la CPU.
4. Perfilar unos segundos. async-profiler o JFR durante 30-60 segundos y mirar el gráfico de llamas: es la forma más directa de ver el bucle caliente.
5. Descartar las causas típicas por frecuencia: bucle infinito o while(true) sin espera; regex con retroceso catastrófico sobre una entrada inesperada; un HashMap mutado concurrentemente (antes de Java 8 podía crear un ciclo y colgar el get); serialización de respuestas gigantes; GC en bucle por fuga de memoria; log en nivel DEBUG activado por error en producción.
6. Arreglar, verificar con la métrica y escribir el postmortem con una acción concreta: normalmente una alerta que lo habría detectado antes.

# La secuencia completa, en el orden en que se teclea
top -H -p $(pgrep -f mi-app)           # 1. hilo que consume, PID en decimal
printf '%x\n' 12345                     # 2. a hexadecimal → 0x3039
jcmd <pid> Thread.print > td1.txt       # 3. volcado
grep -A 25 '0x3039' td1.txt             # 4. la pila del culpable

# Tres volcados separados: si la pila no cambia, es un bucle
for i in 1 2 3; do jcmd <pid> Thread.print > td$i.txt; sleep 5; done

# Perfil con JFR, sin parar el servicio
jcmd <pid> JFR.start duration=60s filename=/tmp/perfil.jfr settings=profile

Trampa: la respuesta perdedora es «reiniciaría el servicio». Reiniciar puede ser parte de la contención, pero si reinicias sin tomar el volcado ni el perfil, has destruido la evidencia y el problema volverá. La frase que hay que decir es: «capturo el thread dump y un perfil antes de reiniciar».

Una fuga en Java no es memoria «perdida»: es memoria alcanzable pero inútil. El GC hace su trabajo perfectamente; el problema es que algo mantiene una referencia viva.

1. Confirmar que es una fuga y no un heap pequeño. La señal inequívoca está en los logs de GC: si el heap ocupado después de un full GC crece de forma monótona a lo largo de horas o días, es una fuga. Si sube y baja en diente de sierra volviendo siempre al mismo nivel, no lo es.
2. Capturar dos heap dumps separados por una o dos horas de tráfico normal.
3. Comparar con Eclipse MAT (histograma comparado y árbol de dominadores). La pregunta que responde MAT es la única que importa: ¿quién retiene esto?.
4. Buscar los sospechosos habituales, que cubren casi todos los casos reales:

Y la parte que casi nadie menciona y que cierra la respuesta: añadir una alerta sobre memoria usada tras full GC y un test que lo cubra si es posible (por ejemplo, comprobar que la caché no supera su tamaño máximo). Arreglar la fuga sin poner el detector es garantizar que la próxima también se descubra por una caída.

Trampa: «¿usarías System.gc()?». Nunca en producción: es una sugerencia, no una orden, y con la mayoría de los recolectores provoca un full GC con pausa. La única excepción legítima es forzar una colección antes de tomar un heap dump para no ver basura todavía no recogida, y para eso el propio jcmd GC.heap_dump ya lo hace.

La JVM empieza interpretando el bytecode y, según ve qué métodos se ejecutan mucho (hot spots), los compila a código máquina y aplica optimizaciones muy agresivas basadas en el perfil de ejecución real. Por eso el mismo código puede ser diez o cien veces más rápido tras unos miles de ejecuciones.

Compilación por niveles (tiered):
  Nivel 0  · intérprete
  Nivel 1-3 · C1: compila rápido, optimiza poco, recoge perfil
  Nivel 4  · C2: compila despacio, optimiza muchísimo (con el perfil de C1)

Optimizaciones clave que hace C2:
  · Inlining: mete el cuerpo del método llamado en el llamante (la más importante).
  · Escape analysis: si un objeto no escapa del método, puede no asignarlo en el heap.
  · Desvirtualización: si en la práctica solo se ha visto una implementación de una
    interfaz, la llama directamente (con una guarda por si aparece otra).
  · Eliminación de código muerto, desenrollado de bucles, vectorización.

Deoptimización: si una suposición se rompe (aparece una segunda implementación,
una rama que nunca se había tomado), C2 descarta el código y vuelve al intérprete.

Consecuencias prácticas que se preguntan mucho:

• Las primeras peticiones son lentas. Un servicio recién arrancado tiene p99 malísimo durante decenas de segundos. Por eso los despliegues necesitan readiness con margen, y por eso a veces se hace warm-up con tráfico sintético antes de meter la instancia en el balanceador.
• Los microbenchmarks caseros mienten. Sin calentamiento estás midiendo el intérprete. Es la razón de ser de JMH.
• El megamorfismo cuesta. Un punto de llamada con más de dos implementaciones distintas no se puede desvirtualizar ni inlinear; es un argumento real (y medible) contra las jerarquías de interfaces excesivas en bucles calientes.
• Alternativas al calentamiento: CDS/AppCDS (comparte metadatos de clases y mejora el arranque), Project Leyden y los ahead-of-time caches de Java 24+, o GraalVM native image, que compila antes de ejecutar y arranca en milisegundos a cambio de perder el pico de rendimiento del JIT y de exigir configuración explícita de reflexión.

Trampa: «¿es Java más lento que C++ por el JIT?». La respuesta con criterio: en régimen estacionario, el JIT compite muy bien porque optimiza con información que un compilador estático no tiene (qué ramas se toman de verdad, qué tipos aparecen). Donde Java pierde es en el arranque, en la huella de memoria y en el control fino del diseño de memoria. Y ese es exactamente el hueco que intentan tapar Valhalla y los proyectos de arranque rápido.

Los bugs de concurrencia no se depuran con el depurador: poner un breakpoint cambia los tiempos y el problema desaparece (el clásico heisenbug). La estrategia es otra: hacerlo determinista para poder verlo.

1. Escribe un test que fuerce el entrelazado. N hilos arrancando a la vez con un CountDownLatch, miles de iteraciones y comprobación del invariante al final. Repite el test cien veces: si falla una, tienes el bug.
2. Añade estrés artificial: más hilos que núcleos, y Thread.yield() o una espera microscópica en el punto sospechoso para ampliar la ventana de la carrera.
3. Usa herramientas de detección: -XX:+PrintConcurrentLocks en los volcados, jcstress para invariantes del modelo de memoria, y análisis estático (SpotBugs con los detectores de concurrencia, Error Prone con las anotaciones de @GuardedBy).
4. Documenta el modelo de sincronización con anotaciones @ThreadSafe/@GuardedBy("cerrojo"): la mayoría de estos bugs vienen de que nadie sabía qué cerrojo protegía qué campo.
5. Si el estado compartido está en la base de datos, el test es distinto: dos transacciones concurrentes reales con Testcontainers, y comprobar que la segunda falla con conflicto de versión o espera el bloqueo. Ese test sí es determinista.

@Test void no_debe_perder_incrementos() throws Exception {
    var contador = new Contador();
    int hilos = 50, vueltas = 1_000;
    var arranque = new CountDownLatch(1);
    var fin = new CountDownLatch(hilos);

    try (var ex = Executors.newVirtualThreadPerTaskExecutor()) {
        for (int i = 0; i < hilos; i++) {
            ex.submit(() -> {
                arranque.await();                       // todos salen a la vez
                for (int j = 0; j < vueltas; j++) contador.incrementar();
                fin.countDown();
                return null;
            });
        }
        arranque.countDown();
        assertTrue(fin.await(10, TimeUnit.SECONDS));
    }
    assertEquals(hilos * vueltas, contador.valor());     // 50.000 exactos
}

Trampa: «¿y si el test pasa siempre?». Entonces no has demostrado que no haya bug, solo que no lo has reproducido: la ausencia de fallo en un test de concurrencia es evidencia débil. Reconocerlo es señal de rigor. Lo fuerte es razonar sobre el modelo de memoria y sobre qué cerrojo protege qué, y usar el test como red de seguridad adicional.

Contrapresión es la capacidad de un consumidor para frenar al productor cuando no puede seguir su ritmo. Sin ella, el exceso de trabajo se acumula en algún sitio —una cola, un pool, un buffer— hasta que algo se rompe, y normalmente lo que se rompe es la memoria.

// 1. Cola acotada: la forma más simple y más efectiva
new ArrayBlockingQueue<Tarea>(1000);      // put() bloquea al productor

// 2. Semáforo: limitar la concurrencia hacia una dependencia frágil
private final Semaphore permisos = new Semaphore(20);   // máximo 20 en vuelo
public Respuesta llamar(Peticion p) {
    if (!permisos.tryAcquire(200, TimeUnit.MILLISECONDS)) {
        throw new SistemaSobrecargado();                 // → 503 + Retry-After
    }
    try { return clienteRemoto.enviar(p); } finally { permisos.release(); }
}

// 3. CallerRunsPolicy: el que produce, procesa; se frena solo
new ThreadPoolExecutor(..., new ThreadPoolExecutor.CallerRunsPolicy());

// 4. En la capa HTTP: rechazar antes de aceptar trabajo que no puedes hacer
//    Bulkhead de Resilience4j, o un rate limiter con 429 y Retry-After.

// 5. En Kafka: max.poll.records y la propia velocidad de commit son la contrapresión
//    natural. El broker guarda el trabajo; tú consumes al ritmo que puedes.

El principio que hay que verbalizar: rechazar rápido es mejor que aceptar y morir. Un 503 inmediato con Retry-After es una respuesta útil que el cliente puede gestionar; un timeout a los treinta segundos después de haber consumido recursos es lo peor de los dos mundos, porque has pagado el coste y además has fallado.

Trampa: los hilos virtuales quitan el límite natural que suponían los hilos de plataforma, así que hacen la contrapresión explícita más necesaria, no menos. Antes, tener 200 hilos de Tomcat era un límite de admisión accidental; ahora puedes aceptar cien mil peticiones simultáneas y hundir la base de datos. Ese razonamiento es exactamente el tipo de matiz que buscan en una entrevista de senior.

Inversión de control es el principio: la creación y el ciclo de vida de los objetos lo controla el contenedor, no cada clase. Inyección de dependencias es la técnica concreta: las dependencias llegan desde fuera en lugar de instanciarse dentro.

El problema que resuelve no es «escribir menos new», es el acoplamiento a implementaciones concretas, que te impide sustituir, probar y evolucionar.

// ❌ Sin DI: la clase decide con qué colabora → imposible probar sin base de datos real
class ServicioPedidos {
    private final RepositorioPedidos repo = new RepositorioJdbc(DriverManager.getConnection(...));
    private final PasarelaPago pago = new PasarelaStripe("clave-de-produccion");
}

// ✅ Con DI: dependencias explícitas, sustituibles y visibles en la firma
@Service
class ServicioPedidos {
    private final RepositorioPedidos repo;
    private final PasarelaPago pago;

    ServicioPedidos(RepositorioPedidos repo, PasarelaPago pago) {   // el contrato está aquí
        this.repo = repo;
        this.pago = pago;
    }
}
// En un test: new ServicioPedidos(new RepoEnMemoria(), new PagoFalso()) — sin Spring.

El beneficio secundario, que en Spring es enorme: al controlar la creación, el contenedor puede envolver los beans en proxies y añadir transacciones, caché, seguridad, métricas o reintentos sin que tu código lo sepa. Toda la parte declarativa de Spring depende de la inversión de control.

Trampa: «¿el constructor con seis parámetros no es incómodo?». Sí, y es una señal: un constructor con muchas dependencias suele indicar que la clase hace demasiado. La inyección por campo lo esconde; la inyección por constructor lo hace visible, y eso es una ventaja, no un inconveniente.

Por cinco razones concretas, y merece la pena decirlas todas porque es una pregunta de criba:

1. El objeto siempre está válido. No existe un estado intermedio en el que el bean esté construido pero sin dependencias.
2. Campos final. Inmutabilidad y seguridad entre hilos gratis.
3. Dependencias explícitas. La firma del constructor es la documentación. Si tiene ocho parámetros, el diseño te está avisando.
4. Testeable sin framework. new ServicioPedidos(repoFalso, pagoFalso) y ya: sin @SpringBootTest, sin reflexión, sin @InjectMocks.
5. Los ciclos de dependencias fallan al arrancar, no en la petición 500. Con inyección por campo, Spring puede resolver algunos ciclos y dejarte un problema latente.

// ❌ Inyección por campo
@Service class ServicioPedidos {
    @Autowired private RepositorioPedidos repo;   // no puede ser final, oculta la dependencia
}
// En un test necesitas reflexión o ReflectionTestUtils para ponerle un doble.

// ✅ Por constructor, y con un solo constructor NO hace falta @Autowired (desde Spring 4.3)
@Service
class ServicioPedidos {
    private final RepositorioPedidos repo;
    ServicioPedidos(RepositorioPedidos repo) { this.repo = repo; }
}

// ✅ Con Lombok, si el proyecto ya lo usa
@Service @RequiredArgsConstructor
class ServicioPedidos { private final RepositorioPedidos repo; }

La inyección por setter tiene un hueco legítimo: dependencias verdaderamente opcionales o reconfigurables en caliente. Es raro.

Trampa: la repregunta es «¿y si hay una dependencia circular?». La respuesta correcta no es @Lazy: es que el ciclo es un problema de diseño. Se rompe extrayendo la responsabilidad compartida a una tercera clase, o invirtiendo la relación con un evento de dominio. Spring Boot 2.6+ prohíbe los ciclos por defecto precisamente por eso.

Técnicamente los cuatro son @Component: los detecta el mismo escaneo y producen un bean idéntico. Las diferencias reales son dos: semántica (documentan la capa, y las herramientas y los compañeros lo leen) y comportamiento añadido en dos de ellos.

La traducción de excepciones de @Repository es la respuesta que se busca: gracias a ella tu capa de servicio puede capturar DuplicateKeyException u OptimisticLockingFailureException sin depender del proveedor concreto, y podrías cambiar de JPA a JDBC sin tocar el manejo de errores. Con Spring Data ya la tienes de serie porque las interfaces de repositorio la aplican.

Trampa: usar @Service en una clase que solo hace acceso a datos, o @Component en todo. Funciona, y por eso mucha gente cree que da igual; pero la entrevista busca precisamente que sepas que @Repository no es decorativo.

Estereotipo (@Service, @Component…) para tus clases: Spring las descubre por escaneo. @Bean en un @Configuration para clases que no controlas (de una librería) o cuando la construcción requiere lógica.

@Configuration
class ConfiguracionClientes {

    // Clase de terceros: no puedo anotarla, así que la construyo yo
    @Bean
    RestClient clientePagos(RestClient.Builder builder,
                            @Value("${pagos.url}") String url) {
        return builder.baseUrl(url)
                .requestFactory(factoriaConTimeouts(2000, 5000))
                .defaultHeader("X-Origen", "pedidos")
                .build();
    }

    // Construcción condicional: imposible con un estereotipo
    @Bean
    @ConditionalOnProperty(name = "cache.tipo", havingValue = "redis")
    CacheManager cacheRedis(RedisConnectionFactory f) { return RedisCacheManager.create(f); }

    // Varios beans del mismo tipo con configuración distinta
    @Bean @Primary TaskExecutor ejecutorGeneral() { ... }
    @Bean("ejecutorInformes") TaskExecutor ejecutorInformes() { ... }
}

Un detalle que casi nadie sabe y que impresiona: el nombre del bean es el nombre del método, así que renombrar un método @Bean puede romper una inyección por nombre o un @Qualifier. Y los parámetros del método @Bean son inyección de dependencias: Spring los resuelve del contexto y además establece el orden de creación.

Trampa: declarar un @Bean de una de tus propias clases que ya tiene @Component crea dos beans del mismo tipo y provoca un NoUniqueBeanDefinitionException al inyectar. Elige uno de los dos mecanismos por clase.

@Configuration marca una clase como fuente de definiciones de beans y, por defecto, Spring la subclasea con CGLIB. Ese proxy intercepta las llamadas entre métodos @Bean para que devuelvan siempre la misma instancia en lugar de ejecutar el método otra vez.

@Configuration                       // proxyBeanMethods = true por defecto
class Config {
    @Bean A a() { return new A(); }
    @Bean B b() { return new B(a()); }   // ← a() NO crea otra A: el proxy devuelve el singleton
    @Bean C c() { return new C(a()); }   // ← la misma instancia de A que en b()
}

@Configuration(proxyBeanMethods = false)   // "modo ligero": sin proxy CGLIB
class ConfigLigera {
    @Bean A a() { return new A(); }
    @Bean B b() { return new B(a()); }   // ⚠ AHORA a() SÍ crea una A nueva
    @Bean B b(A a) { return new B(a); }   // ✅ la forma correcta: pedirla por parámetro
}

¿Por qué existe proxyBeanMethods = false? Porque el proxy CGLIB cuesta tiempo de arranque y memoria, y estorba a la compilación nativa de GraalVM. Todas las autoconfiguraciones de Spring Boot lo usan, y es la razón por la que Boot arranca más rápido que hace unos años. La regla: si tus métodos @Bean no se llaman entre sí (y no deberían: pide las dependencias por parámetro), desactívalo.

Trampa: con proxyBeanMethods = false y un método que llama a otro, tendrás dos instancias del mismo bean y un bug desconcertante: cambias la configuración en una y no se refleja en la otra. Es un error muy difícil de ver leyendo el código.

De principio a fin, con los puntos donde puedes intervenir:

1. Se lee la definición del bean (escaneo, @Bean, XML, registro programático).
2. BeanFactoryPostProcessor puede MODIFICAR las definiciones
   (aquí actúa, por ejemplo, PropertySourcesPlaceholderConfigurer).
3. Instanciación: se llama al constructor (con inyección por constructor).
4. Inyección de propiedades y de campos (@Autowired en campos, @Value).
5. Callbacks de conocimiento del contenedor: BeanNameAware, BeanFactoryAware,
   ApplicationContextAware.
6. BeanPostProcessor.postProcessBeforeInitialization
7. @PostConstruct → InitializingBean.afterPropertiesSet() → initMethod de @Bean
8. BeanPostProcessor.postProcessAfterInitialization
   ← AQUÍ se crean los PROXIES (@Transactional, @Async, @Cacheable, seguridad)
9. El bean está listo y en uso.
--- al cerrar el contexto ---
10. @PreDestroy → DisposableBean.destroy() → destroyMethod de @Bean
    (solo para singletons: los beans prototype NO reciben destrucción)

El paso 8 es la respuesta a un montón de preguntas aparentemente inconexas: por qué @Transactional no funciona si llamas al método desde dentro de la misma clase, por qué no puedes usar un bean proxificado dentro de su propio @PostConstruct esperando que las anotaciones apliquen, y por qué al inyectar un bean recibes a veces un objeto cuya clase termina en $$SpringCGLIB$$.

Para lógica de arranque en una aplicación real, hoy se prefiere ApplicationRunner o CommandLineRunner —o un @EventListener(ApplicationReadyEvent.class)— porque se ejecutan cuando todo el contexto está listo, no a mitad de la construcción de un bean.

Trampa: «¿por qué mi @Value es null en el constructor?» Porque los campos se inyectan en el paso 4, después del constructor (paso 3). Si necesitas el valor en la construcción, pásalo como parámetro del constructor con @Value en el parámetro.

singleton (por defecto, una instancia por contexto), prototype (una nueva en cada inyección o petición al contenedor) y los de ámbito web: request, session, application y websocket.

La verdad práctica: el 98 % de los beans son singleton y sin estado, y eso es lo correcto. Los demás ámbitos casi siempre son una señal de que se está guardando estado donde no toca.

// ⚠ El bug clásico: estado de la petición en un singleton
@Service
class ServicioMal {
    private String usuarioActual;            // ← compartido por TODOS los hilos
    void procesar(String usuario) {
        this.usuarioActual = usuario;         // dos peticiones simultáneas se pisan
        // ...
    }
}

// Si de verdad necesitas un bean con estado por petición:
@Bean @Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
ContextoPeticion contexto() { return new ContextoPeticion(); }
// El proxyMode es obligatorio para poder inyectarlo en un singleton: el proxy
// resuelve la instancia correcta en cada llamada.

// Un prototype inyectado en un singleton se resuelve UNA VEZ: si necesitas uno nuevo
// en cada llamada, inyecta ObjectProvider (o una factoría)
private final ObjectProvider<Informe> informes;
Informe nuevo() { return informes.getObject(); }

Trampa: «un singleton de Spring es seguro entre hilos, ¿no?». No: Spring garantiza una instancia, no seguridad. Es seguro si no guarda estado mutable. Y la forma correcta de tener contexto de petición no suele ser un bean con scope, es pasar el dato como parámetro o usar el contexto que ya ofrece el framework (SecurityContextHolder, MDC).

Con @Primary, @Qualifier o coincidencia por nombre. El orden de resolución de Spring: primero por tipo; si hay varios candidatos, aplica @Qualifier; si no lo hay, busca un @Primary; si tampoco, intenta coincidir el nombre del parámetro con el nombre del bean; y si nada funciona, falla el arranque con NoUniqueBeanDefinitionException.

@Bean @Primary PasarelaPago stripe() { ... }        // la elegida por defecto
@Bean("paypal") PasarelaPago paypal() { ... }

@Service
class ServicioPagos {
    ServicioPagos(PasarelaPago pasarela,                        // → stripe (@Primary)
                  @Qualifier("paypal") PasarelaPago alternativa) { ... }
}

// Mejor que @Qualifier con cadenas: un qualifier con tipo, que el compilador comprueba
@Qualifier @Retention(RUNTIME) @interface Paypal { }
@Bean @Paypal PasarelaPago paypal() { ... }
ServicioPagos(@Paypal PasarelaPago p) { ... }

// Elegir por configuración: la forma más limpia de todas
@Bean @ConditionalOnProperty(name = "pagos.proveedor", havingValue = "stripe")
PasarelaPago stripe() { ... }

Trampa: depender de la coincidencia por nombre del parámetro es frágil: si alguien renombra el parámetro (o compilas sin -parameters), la inyección cambia de bean en silencio. Usa @Qualifier explícito cuando haya más de un candidato.

Sí, y es uno de los patrones más útiles de Spring: inyectar List, Set o Map de un tipo y recibir todos los beans que lo implementan. Con Map, la clave es el nombre del bean.

interface Validador { void validar(Pedido p); }

@Component @Order(1) class ValidadorStock implements Validador { ... }
@Component @Order(2) class ValidadorCredito implements Validador { ... }
@Component @Order(3) class ValidadorDireccion implements Validador { ... }

@Service
class ServicioPedidos {
    private final List<Validador> validadores;     // los tres, EN ORDEN por @Order

    ServicioPedidos(List<Validador> validadores) { this.validadores = validadores; }

    void crear(Pedido p) {
        validadores.forEach(v -> v.validar(p));      // añadir una regla = añadir una clase
    }
}

// Con Map: strategy por clave, sin ningún switch
@Component("es") class ImpuestoES implements Impuesto { ... }
@Component("pt") class ImpuestoPT implements Impuesto { ... }

@Service
class Calculadora {
    private final Map<String, Impuesto> porPais;
    Calculadora(Map<String, Impuesto> porPais) { this.porPais = porPais; }
}

Por qué esto es tan valioso en entrevista: es la implementación idiomática del principio abierto-cerrado en Spring. Añadir una regla de negocio nueva es añadir una clase, sin tocar ni una línea del código existente y sin ningún if ni switch que crezca con cada requisito.

Trampa: si no hay ninguna implementación, inyectar una List falla al arrancar. Para hacerlo opcional, usa ObjectProvider<List<Validador>> o @Autowired(required = false). Y si el orden importa de verdad, hazlo explícito con @Order: no dependas del orden del escaneo, que no está garantizado.

Es un mecanismo de configuración condicional basado en lo que hay en el classpath y en las propiedades. Los pasos exactos:

1. @SpringBootApplication incluye @EnableAutoConfiguration.
2. AutoConfigurationImportSelector lee TODOS los ficheros del classpath en
   META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
   (antes de Boot 2.7 era META-INF/spring.factories).
3. Obtiene una lista de ~150 clases candidatas de @AutoConfiguration.
4. Filtra por las condiciones de cada una ANTES de cargar la clase (para no pagar
   el coste de clases que no aplican).
5. Las que sobreviven se procesan como @Configuration, después de las tuyas
   (por eso @ConditionalOnMissingBean funciona: tu bean ya existe).
6. Cada @Bean interno vuelve a tener sus propias condiciones.

Las condiciones que hay que saber nombrar:

// Un starter propio, completo y mínimo
@AutoConfiguration
@ConditionalOnClass(ClienteFacturacion.class)
@EnableConfigurationProperties(FacturacionProperties.class)
class FacturacionAutoConfiguration {

    @Bean
    @ConditionalOnMissingBean                       // el usuario puede poner el suyo
    @ConditionalOnProperty(prefix = "facturacion", name = "enabled", matchIfMissing = true)
    ClienteFacturacion clienteFacturacion(FacturacionProperties props) {
        return new ClienteFacturacion(props.url(), props.timeout());
    }
}
// Y se registra en:
// src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

La herramienta de diagnóstico que hay que mencionar: arrancar con --debug imprime el informe de condiciones con tres secciones —coincidencias positivas, negativas y exclusiones—. Ante cualquier «¿por qué no se ha configurado esto?», ese informe da la respuesta en treinta segundos.

Trampa: «¿la autoconfiguración va antes o después de mi configuración?». Después, siempre. Si va antes, @ConditionalOnMissingBean no podría funcionar. Y por eso definir tu propio DataSource desactiva el de Boot sin que tengas que excluir nada.

@ConfigurationProperties para cualquier configuración con más de dos propiedades relacionadas; @Value solo para valores sueltos y puntuales. La diferencia decisiva es que @ConfigurationProperties se puede validar, es tipada, agrupa, admite relajación de nombres y se documenta sola.

// ✅ Configuración tipada, inmutable y validada al arrancar
@ConfigurationProperties(prefix = "pagos")
@Validated
public record PagosProperties(
        @NotBlank String url,
        @NotNull Duration timeout,
        @Min(0) @Max(10) int reintentos,
        @NotNull @Valid Credenciales credenciales) {

    public record Credenciales(@NotBlank String clave, @NotBlank String secreto) { }
}

// Registro (o @ConfigurationPropertiesScan en la clase principal)
@EnableConfigurationProperties(PagosProperties.class)

// application.yml — relajación de nombres: pagos.timeout, PAGOS_TIMEOUT, pagos-timeout
pagos:
  url: https://api.pasarela.example
  timeout: 3s              # se convierte a Duration automáticamente
  reintentos: 3
  credenciales:
    clave: ${PAGOS_CLAVE}
    secreto: ${PAGOS_SECRETO}

El beneficio que hay que subrayar: con @Validated, una configuración mal puesta hace que la aplicación no arranque, con un mensaje claro de qué propiedad falta. Sin ello, el fallo aparece a las tres de la mañana en la primera petición que use ese valor. Es el principio de fallar pronto y ruidoso aplicado a la configuración.

Trampa: @Value en un campo se inyecta después del constructor, así que no puedes usarlo en el constructor, y con SpEL (#{...}) es fácil escribir configuración imposible de depurar. Además @Value no aparece en los metadatos de configuración, así que el autocompletado del IDE no lo conoce.

Los perfiles activan condicionalmente beans y ficheros de configuración. El orden de precedencia de las fuentes de propiedades es lo que se pregunta, porque explica el 90 % de los «¿por qué coge este valor y no el mío?».

De MAYOR a MENOR prioridad (lo de arriba gana):

 1. Devtools en $HOME/.config/spring-boot (solo desarrollo)
 2. @TestPropertySource y properties de @SpringBootTest
 3. Argumentos de línea de comandos:  --server.port=8081
 4. SPRING_APPLICATION_JSON (JSON en línea o en variable de entorno)
 5. ServletConfig / ServletContext init params
 6. JNDI (java:comp/env)
 7. Propiedades del sistema Java:  -Dserver.port=8081
 8. Variables de entorno:  SERVER_PORT=8081     ← la habitual en Docker/K8s
 9. application-{perfil}.yml FUERA del jar (config/ o directorio de trabajo)
10. application-{perfil}.yml dentro del jar
11. application.yml fuera del jar
12. application.yml dentro del jar
13. @PropertySource
14. SpringApplication.setDefaultProperties

spring:
  application:
    name: pedidos
  profiles:
    group:
      produccion: [ "prod-db", "prod-cache", "observabilidad" ]  # perfil compuesto
---
spring:
  config:
    activate:
      on-profile: dev            # documento condicional en el mismo fichero
logging:
  level:
    org.hibernate.SQL: debug

Buenas prácticas que conviene añadir: no metas secretos en application.yml (van en variables de entorno o en un gestor de secretos), evita @Profile en beans de negocio (mejor @ConditionalOnProperty, que es más explícito y no acopla el código a un nombre de entorno), y no uses un perfil test que cambie la lógica, porque entonces tus tests no prueban lo que se despliega.

Trampa: en Kubernetes las variables de entorno (posición 8) ganan a cualquier application.yml del jar. Si alguien define SERVER_PORT en el Deployment, tu configuración no se aplica y el diagnóstico es desconcertante hasta que conoces esta lista. /actuator/env te dice exactamente de qué fuente sale cada valor.

Merece la pena saberlo con detalle porque es la base para diagnosticar arranques lentos y errores de contexto:

 1. main() → SpringApplication.run(App.class, args)
 2. Se crea el SpringApplication: deduce el tipo de aplicación (servlet, reactiva o
    ninguna) mirando el classpath, y carga los ApplicationContextInitializer y
    ApplicationListener de los ficheros .imports/spring.factories.
 3. Environment: se preparan las fuentes de propiedades y se resuelven los perfiles
    activos. Se publica ApplicationEnvironmentPreparedEvent (aquí engancha la
    configuración externa: Config Server, Vault…).
 4. Banner, y creación del ApplicationContext del tipo adecuado.
 5. Se registran las definiciones de beans: la clase principal, el escaneo de
    componentes y las autoconfiguraciones.
 6. refresh():
    a. BeanFactoryPostProcessors (incluido ConfigurationClassPostProcessor, que
       procesa @Configuration, @Import, @ComponentScan y las condiciones).
    b. Se registran los BeanPostProcessors.
    c. Se crea el servidor web embebido (Tomcat) — pero aún no acepta tráfico.
    d. Se instancian todos los singletons no perezosos, en orden de dependencia.
       Aquí se ejecutan @PostConstruct y se crean los proxies.
 7. ApplicationStartedEvent → se ejecutan ApplicationRunner y CommandLineRunner.
 8. El servidor empieza a aceptar conexiones.
 9. ApplicationReadyEvent → readiness pasa a UP.
10. Se registra el hook de apagado (para el cierre ordenado).

Herramientas para diagnosticar un arranque lento, que es la pregunta que suele venir detrás: --debug para el informe de condiciones, la métrica /actuator/startup con BufferingApplicationStartup para ver el tiempo de cada paso, y las causas habituales: escaneo de componentes demasiado amplio, muchas autoconfiguraciones innecesarias, conexiones a servicios externos en @PostConstruct, y validación de esquema de Hibernate contra una base de datos lenta.

Trampa: hacer trabajo pesado o llamadas de red en un @PostConstruct retrasa el arranque y, peor, si falla, la aplicación no arranca. Ese trabajo va en un ApplicationRunner o en un listener de ApplicationReadyEvent, y con tolerancia a fallos.

Son tres anotaciones en una, y saberlo permite responder «¿cómo limitaría el escaneo?» o «¿cómo excluyo una autoconfiguración?» sin dudar:

@SpringBootApplication
// ≡
@SpringBootConfiguration     // = @Configuration, y marca la clase raíz (la buscan los tests)
@EnableAutoConfiguration     // activa el mecanismo de autoconfiguración
@ComponentScan               // escanea el paquete de esta clase y sus subpaquetes
class Aplicacion { public static void main(String[] a) { SpringApplication.run(Aplicacion.class, a); } }

// Variantes útiles
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)
@SpringBootApplication(scanBasePackages = "com.miempresa.pedidos")
@SpringBootApplication(proxyBeanMethods = false)      // arranque más rápido

// Y en application.yml
spring.autoconfigure.exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

Dos consecuencias prácticas que dan puntos: (1) la clase principal debe estar en el paquete raíz, porque el escaneo parte de ahí; ponerla en un subpaquete es la causa número uno de «no encuentra mis beans». (2) @SpringBootConfiguration es la marca que buscan @SpringBootTest y las slices para localizar la configuración: por eso los tests funcionan sin decirles qué clase cargar, y por eso solo puede haber una por aplicación.

Trampa: «¿y si quiero escanear otro paquete además del mío?» Añadir scanBasePackages con paquetes muy amplios (por ejemplo com) hace el arranque lentísimo y puede cargar beans inesperados de las librerías. Mejor importar explícitamente la configuración de la librería con @Import, o que la librería traiga su propia autoconfiguración.

Spring implementa AOP con proxies en tiempo de ejecución, no con manipulación de bytecode (eso es AspectJ). Cuando un bean tiene un aspecto aplicable, el BeanPostProcessor lo sustituye por un proxy que intercepta las llamadas.

// De aquí salen las tres limitaciones que SIEMPRE preguntan:

@Service
class ServicioPedidos {

    // 1. Autoinvocación: la llamada interna NO pasa por el proxy
    public void procesarTodos(List<Pedido> ps) {
        ps.forEach(this::procesarUno);      // ← this es el objeto real, no el proxy
    }
    @Transactional public void procesarUno(Pedido p) { ... }   // ¡sin transacción!

    // 2. Método privado: CGLIB no puede sobrescribirlo → la anotación se ignora
    @Transactional private void interno() { ... }

    // 3. Método final: idem
    @Transactional public final void tambienIgnorado() { ... }
}

// Soluciones a la autoinvocación, de mejor a peor:
// a) Extraer el método a otro bean e inyectarlo  ← la correcta
// b) Inyectar el propio bean con @Lazy y llamar al proxy
// c) TransactionTemplate programático
// d) AopContext.currentProxy() con exposeProxy=true  ← evítalo

Trampa: el síntoma de la autoinvocación es traicionero porque parece funcionar: en el caso feliz todo se guarda igual y solo descubres el problema cuando algo falla a mitad y no hay rollback. Si en la entrevista cuentas que te pasó y cómo lo detectaste, es una de las mejores historias técnicas que puedes tener preparadas.

Igual que @Transactional: un proxy intercepta la llamada, envía la ejecución a un TaskExecutor y devuelve inmediatamente. Requiere @EnableAsync y tiene las mismas limitaciones de proxy (no funciona en llamadas internas ni en métodos privados).

@Configuration @EnableAsync
class ConfigAsync implements AsyncConfigurer {

    @Bean("ejecutorNotificaciones")
    ThreadPoolTaskExecutor ejecutor() {
        var ex = new ThreadPoolTaskExecutor();
        ex.setCorePoolSize(4);
        ex.setMaxPoolSize(8);
        ex.setQueueCapacity(500);                       // ACOTADA
        ex.setThreadNamePrefix("notif-");               // nombres útiles en los dumps
        ex.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        ex.setWaitForTasksToCompleteOnShutdown(true);    // apagado ordenado
        ex.setAwaitTerminationSeconds(30);
        return ex;
    }

    // Sin esto, las excepciones de métodos void se PIERDEN en silencio
    @Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return (ex, metodo, args) -> log.error("fallo async en {}", metodo.getName(), ex);
    }
}

@Service
class Notificaciones {
    @Async("ejecutorNotificaciones")
    public CompletableFuture<Void> enviar(String destino) { ... }   // mejor que void
}

Los cuatro problemas prácticos que hay que nombrar: (1) si no defines executor, Boot usa uno por defecto —hoy un SimpleAsyncTaskExecutor con hilos virtuales si están activados, y antes un pool que podía crear hilos sin límite—, así que define siempre el tuyo; (2) las excepciones de métodos void se pierden si no hay handler; (3) el contexto no se propaga automáticamente: SecurityContextHolder, el MDC de los logs y la transacción no viajan al hilo nuevo; (4) @Async con @Transactional en el mismo método significa una transacción nueva en el hilo nuevo, no la del llamante.

Trampa: «¿usarías @Async para procesar un pedido en segundo plano?». Con cuidado: si el proceso muere, el trabajo en la cola en memoria se pierde. Para trabajo que no se puede perder, hace falta durabilidad: una tabla de tareas, el patrón outbox o una cola real. @Async es para cosas accesorias (enviar un correo, calentar una caché, registrar auditoría no crítica).

Que la tarea se ejecuta en todas las instancias a la vez. Si el trabajo no es idempotente —enviar recordatorios, cobrar suscripciones, generar informes—, se duplica tantas veces como pods tengas. Es un incidente clásico al pasar de una instancia a tres.

@Scheduled(cron = "0 0 3 * * *", zone = "Europe/Madrid")   // ¡zona explícita!
void cobrarSuscripciones() { ... }

// Soluciones, de más simple a más robusta:

// 1. ShedLock: cerrojo distribuido en la base de datos. Lo más habitual.
@Scheduled(cron = "0 0 3 * * *")
@SchedulerLock(name = "cobros", lockAtMostFor = "30m", lockAtLeastFor = "5m")
void cobrarSuscripciones() { ... }

// 2. Marcar el trabajo en la base de datos con una condición atómica:
//    UPDATE tarea SET estado='EN_CURSO', instancia=? WHERE id=? AND estado='PENDIENTE'
//    Si filas_afectadas = 0, otra instancia se la llevó. Sirve también para reparto.

// 3. Un perfil o una propiedad que solo esté activa en una instancia (frágil:
//    si esa instancia se cae, la tarea no se ejecuta nunca).

// 4. Sacar la programación fuera: un CronJob de Kubernetes que llama a un endpoint,
//    o un planificador gestionado (EventBridge, Cloud Scheduler). Es lo más limpio
//    en un entorno cloud, porque separa "cuándo" de "qué".

// 5. Quartz en modo clúster, si necesitas persistencia de trabajos y reintentos.

Otros detalles importantes de @Scheduled: por defecto todas las tareas comparten un solo hilo, así que una tarea lenta retrasa a las demás (configura spring.task.scheduling.pool.size); las excepciones no capturadas cancelan las ejecuciones siguientes de un fixedDelay, así que envuelve el cuerpo en try/catch; y siempre especifica zone, porque si no usa la del servidor y en marzo y octubre te llevarás una sorpresa.

Trampa: diferencia entre fixedRate y fixedDelay. fixedRate mide desde el inicio de la ejecución anterior, así que si la tarea tarda más que el periodo se van solapando (y con un solo hilo, encolando). fixedDelay mide desde el fin, y por eso es la opción segura por defecto.

Para desacoplar: quien publica no conoce a quien escucha. Es la forma idiomática en Spring de reaccionar a hechos del dominio (un pedido creado) sin que el servicio de pedidos dependa del de notificaciones, del de facturación y del de analítica.

// El evento: un record inmutable con el hecho (en pasado)
record PedidoCreado(String pedidoId, String clienteId, BigDecimal total, Instant cuando) { }

@Service @RequiredArgsConstructor
class ServicioPedidos {
    private final ApplicationEventPublisher eventos;

    @Transactional
    public Pedido crear(CrearPedido cmd) {
        var pedido = repo.save(Pedido.de(cmd));
        eventos.publishEvent(new PedidoCreado(pedido.id(), cmd.clienteId(),
                                              pedido.total(), Instant.now()));
        return pedido;
    }
}

// ⚠ Por defecto los listeners son SÍNCRONOS y en la MISMA transacción:
// si el listener lanza, la transacción del pedido se revierte.
@Component
class Notificador {
    // ✅ Solo después del commit: el pedido ya está guardado
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    void al(PedidoCreado e) { correo.enviarConfirmacion(e.clienteId()); }

    // ✅ Y si además no quieres bloquear la respuesta
    @Async @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    void alAsync(PedidoCreado e) { ... }
}

La trampa principal es la de las dos primeras líneas del listener: por defecto los eventos son síncronos y participan en la transacción del publicador, así que un fallo al enviar el correo puede revertir el pedido. Y la trampa simétrica es la de AFTER_COMMIT: si el listener falla ahí, el pedido ya está guardado y el correo no se envía, sin ningún reintento. Si el efecto es importante, no basta con un evento en memoria: hace falta el patrón outbox, que guarda el evento en la misma transacción y lo publica después con reintentos.

Trampa: los eventos de aplicación son in-process: no cruzan instancias, no sobreviven a un reinicio y no tienen reintentos. Confundirlos con mensajería es un error conceptual grave. Son excelentes para desacoplar módulos dentro de un monolito modular (es la base de Spring Modulith) y no sirven como integración entre servicios.

RestClient para código bloqueante nuevo (introducido en Spring Framework 6.1); WebClient si necesitas reactivo o streaming; RestTemplate solo en código existente: está en modo mantenimiento y no recibirá funcionalidad nueva.

// RestClient: API fluida de WebClient, semántica bloqueante y sin dependencia reactiva
@Bean
RestClient clientePagos(RestClient.Builder builder, PagosProperties props) {
    var factory = new JdkClientHttpRequestFactory();
    factory.setReadTimeout(Duration.ofSeconds(3));        // ← lo más importante
    return builder
            .baseUrl(props.url())
            .requestFactory(factory)
            .defaultStatusHandler(HttpStatusCode::is5xxServerError,
                (req, res) -> { throw new PasarelaNoDisponible(res.getStatusCode()); })
            .requestInterceptor(nuevoInterceptorDeTrazas())
            .build();
}

var respuesta = clientePagos.post()
        .uri("/cobros")
        .header("Idempotency-Key", claveIdempotencia)      // reintento seguro
        .body(new CobroRequest(pedidoId, total))
        .retrieve()
        .body(CobroResponse.class);

// Interfaz declarativa (Spring 6+), el sustituto de Feign sin dependencias extra
interface PagosApi {
    @PostExchange("/cobros") CobroResponse cobrar(@RequestBody CobroRequest r);
}
var api = HttpServiceProxyFactory.builderFor(RestClientAdapter.create(clientePagos))
        .build().createClient(PagosApi.class);

Lo que siempre hay que mencionar, y es el motivo real de la pregunta: los timeouts. Ni RestTemplate ni WebClient los traen configurados por defecto, así que una llamada puede quedarse esperando indefinidamente, agotar los hilos y tumbar tu servicio por culpa de otro. Un cliente HTTP sin timeout de conexión y de lectura es un incidente esperando a ocurrir. Y por encima, un circuit breaker y un límite de reintentos.

Trampa: RestTemplate no está «obsoleto» en el sentido de @Deprecated, y decir que lo está es un error de precisión que algunos entrevistadores corrigen. La formulación correcta es «en modo mantenimiento: se mantiene, pero lo nuevo va a RestClient».

Con recursos en sustantivo plural, verbos HTTP con su semántica, códigos de estado correctos y sin verbos en la URL. Lo que buscan es que conozcas las reglas y que sepas cuándo romperlas de forma consciente.

Recursos y verbos
  GET    /pedidos?estado=PAGADO&page=0&size=20     lista, seguro e idempotente
  GET    /pedidos/{id}                             uno
  POST   /pedidos                                  crear → 201 + Location
  PUT    /pedidos/{id}                             reemplazo completo, idempotente
  PATCH  /pedidos/{id}                             modificación parcial
  DELETE /pedidos/{id}                             borrar, idempotente
  GET    /pedidos/{id}/lineas                      subrecurso
  POST   /pedidos/{id}/cancelaciones               ⚠ acción modelada como recurso

Códigos que hay que usar bien
  200 OK           201 Created (+ Location)     202 Accepted (asíncrono)
  204 No Content   400 Bad Request (sintaxis)   401 (no autenticado)
  403 (no autorizado)  404 (no existe / no es tuyo)  409 Conflict (estado o versión)
  422 Unprocessable (validación de negocio)     429 Too Many Requests (+ Retry-After)
  500 (bug nuestro)   503 (dependencia caída, + Retry-After)

Lo que NO se hace
  POST /crearPedido            ← verbo en la URL
  GET  /pedidos/borrar/5       ← GET que modifica estado
  200 OK con {"error": "..."}  ← el código de estado ES parte de la respuesta
  Exponer la entidad JPA       ← acoplas el esquema a la API

Idempotencia: GET, PUT y DELETE lo son por definición; POST no. Para que un POST se pueda reintentar sin duplicar (pagos, pedidos) se usa una cabecera Idempotency-Key que el servidor almacena con el resultado: si llega otra vez la misma clave, se devuelve la respuesta original.

Paginación: page y size para catálogos pequeños; cursor (keyset) para listas grandes o infinitas, porque OFFSET grande es lento y además se duplican o se saltan filas si alguien inserta mientras el usuario navega. Devuelve siempre el total o el enlace al siguiente, y pon un límite máximo de size: sin él, un cliente puede pedir un millón de filas y tumbarte.

Versionado: prefijo de ruta (/v1/pedidos) es lo más práctico y lo que más se usa; cabecera de contenido (Accept: application/vnd.empresa.v2+json) es más purista y más incómodo de probar. Lo importante es la regla de evolución: añadir campos opcionales nunca rompe; quitar o renombrar sí, y entonces hace falta versión nueva y periodo de convivencia.

HATEOAS: honestidad: es elegante y casi nadie lo usa, porque los clientes reales no navegan hipermedia. Merece la pena si tienes muchos clientes que no controlas y flujos con estados; para una API interna consumida por tu propio frontend, añade complejidad sin beneficio.

Trampa: 404 frente a 403 cuando el recurso existe pero no es del usuario. Devolver 403 confirma que el recurso existe, lo que es una fuga de información (enumeración). Devuelve 404. Es un detalle pequeño que demuestra mentalidad de seguridad.

La validación de formato va en el DTO de entrada con anotaciones, y se activa con @Valid en el controlador. La validación de reglas de negocio va en el dominio, y no es lo mismo: «el email tiene formato válido» es formato; «este cliente no puede pedir a crédito» es negocio.

public record CrearPedidoRequest(
        @NotBlank @Size(max = 36) String clienteId,
        @NotEmpty @Valid List<LineaRequest> lineas,     // @Valid en cascada
        @Email String emailContacto,
        @Future LocalDate entregaDeseada,
        @Positive @Digits(integer = 8, fraction = 2) BigDecimal total) { }

@PostMapping("/pedidos")
ResponseEntity<PedidoResponse> crear(@Valid @RequestBody CrearPedidoRequest req) { ... }
// Si falla → MethodArgumentNotValidException → 400 (lo maneja el @RestControllerAdvice)

// Validación en parámetros y en la capa de servicio
@Validated                                    // necesario a nivel de clase
@Service
class ServicioPedidos {
    Pedido buscar(@NotBlank String id) { ... }   // → ConstraintViolationException
}

// Grupos: la misma clase con reglas distintas según la operación
interface Crear { } interface Actualizar { }
record ClienteRequest(
        @Null(groups = Crear.class) @NotNull(groups = Actualizar.class) Long id,
        @NotBlank(groups = { Crear.class, Actualizar.class }) String nombre) { }

@PostMapping void crear(@Validated(Crear.class) @RequestBody ClienteRequest r) { }
@PutMapping  void editar(@Validated(Actualizar.class) @RequestBody ClienteRequest r) { }

// Validador propio para una regla que no cubren las anotaciones estándar
@Constraint(validatedBy = NifValidator.class)
@Target(FIELD) @Retention(RUNTIME)
public @interface Nif { String message() default "NIF no válido"; }

Trampa: @Valid frente a @Validated. @Valid es de Jakarta Bean Validation y sirve para cascada; @Validated es de Spring, admite grupos y es la que habilita la validación por AOP en métodos de beans. Y la regla de fondo: la validación del cliente nunca sustituye a la del servidor; la del cliente es experiencia de usuario, la del servidor es la única real.

Con un @RestControllerAdvice centralizado y el formato estándar ProblemDetail (RFC 9457, antes 7807), que Spring 6 trae de serie. Un formato único de error es una de las cosas que más agradecen los consumidores de una API y una de las que más se olvidan.

@RestControllerAdvice
class ManejadorErrores extends ResponseEntityExceptionHandler {

    @ExceptionHandler(PedidoNoEncontrado.class)
    ProblemDetail noEncontrado(PedidoNoEncontrado e) {
        var pd = ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, e.getMessage());
        pd.setTitle("Pedido no encontrado");
        pd.setType(URI.create("https://api.miempresa.com/errores/pedido-no-encontrado"));
        pd.setProperty("pedidoId", e.pedidoId());
        pd.setProperty("traceId", traza.actual());          // para correlacionar con logs
        return pd;
    }

    @ExceptionHandler(ObjectOptimisticLockingFailureException.class)
    ProblemDetail conflicto(Exception e) {
        return ProblemDetail.forStatusAndDetail(HttpStatus.CONFLICT,
                "El recurso ha sido modificado por otro usuario. Recárgalo e inténtalo de nuevo.");
    }

    // Validación: devolver TODOS los errores de campo, no solo el primero
    @Override
    protected ResponseEntity<Object> handleMethodArgumentNotValid(
            MethodArgumentNotValidException e, HttpHeaders h, HttpStatusCode s, WebRequest r) {
        var pd = ProblemDetail.forStatus(HttpStatus.BAD_REQUEST);
        pd.setTitle("Datos de entrada no válidos");
        pd.setProperty("errores", e.getBindingResult().getFieldErrors().stream()
                .map(f -> Map.of("campo", f.getField(), "mensaje", f.getDefaultMessage()))
                .toList());
        return ResponseEntity.badRequest().body(pd);
    }

    // La red de seguridad: nunca filtrar detalles internos
    @ExceptionHandler(Exception.class)
    ProblemDetail inesperado(Exception e) {
        log.error("error no controlado", e);                 // el detalle, al log
        var pd = ProblemDetail.forStatusAndDetail(HttpStatus.INTERNAL_SERVER_ERROR,
                "Error interno. Referencia: " + traza.actual());
        return pd;                                           // al cliente, lo mínimo
    }
}

# Y desactivar la fuga de información por defecto
server:
  error:
    include-stacktrace: never
    include-message: never
    include-exception: false

Trampa: devolver el mensaje de la excepción al cliente. Un DataIntegrityViolationException lleva el SQL, el nombre de la restricción y a veces datos de otras filas; una NullPointerException revela rutas internas. La regla es: al log el detalle completo con el traceId, al cliente un mensaje útil y ese mismo identificador. Así soporte puede encontrar el error exacto sin exponer nada.

Por cinco motivos, y conviene decirlos porque es una pregunta de criterio de diseño:

1. Acoplas el contrato público al esquema de la base de datos. Renombrar una columna se convierte en un cambio incompatible para todos tus clientes.
2. Fuga de datos. Todos los campos salen: el hash de la contraseña, el margen interno, las notas del comercial, la columna de auditoría con el usuario que lo modificó.
3. Serialización de relaciones perezosas. Jackson toca los getters, dispara la carga de las asociaciones y provocas un N+1 o una LazyInitializationException según el estado de la sesión. Y con relaciones bidireccionales, recursión infinita.
4. Vulnerabilidad de asignación masiva. Si aceptas la entidad como entrada, un cliente puede enviar campos que no debería tocar (estado, rol, id) y el binding los asigna.
5. No puedes evolucionar. Una API necesita agregar, calcular y renombrar; la entidad necesita reflejar la tabla. Son dos modelos con motivos de cambio distintos.

// La estructura correcta: tres modelos con tres responsabilidades
record CrearPedidoRequest(String clienteId, List<LineaRequest> lineas) { }   // entrada
@Entity class Pedido { ... }                                                 // persistencia
record PedidoResponse(String id, String estado, BigDecimal total,
                      int numeroLineas, Instant creado) { }                  // salida

// Y una proyección directa cuando solo necesitas leer: evita cargar la entidad entera
interface PedidoRepo extends JpaRepository<Pedido, Long> {
    @Query("""
           select new com.x.PedidoResumen(p.id, p.estado, p.total, size(p.lineas))
             from Pedido p where p.clienteId = :cliente
           """)
    List<PedidoResumen> resumenPorCliente(String cliente);
}

El coste es el mapeo, y hay que reconocerlo: más clases y una conversión. Con MapStruct se genera en compilación (sin reflexión, con errores en tiempo de compilación si algo no cuadra) y con records pequeños a mano es media docena de líneas. El intercambio vale la pena en cualquier API que vaya a durar.

Trampa: «¿y para un CRUD interno pequeño?». Se puede admitir como atajo consciente, pero di el riesgo y la condición de salida: «en un CRUD interno lo he hecho, sabiendo que el día que la API tenga un cliente externo hay que introducir DTOs». Reconocer el atajo con criterio puntúa; no ver el problema, no.

Depende del tamaño: a mano si son pocos DTO y el mapeo es trivial (un método factoría estático en el propio record es lo más simple y explícito); MapStruct cuando hay decenas de mapeos, porque genera el código en compilación y avisa si un campo se queda sin mapear.

// A mano: explícito, sin dependencias, imposible de romper en silencio
record PedidoResponse(String id, String estado, BigDecimal total) {
    static PedidoResponse de(Pedido p) {
        return new PedidoResponse(p.getId().toString(), p.getEstado().name(), p.getTotal());
    }
}

// MapStruct: genera la implementación en tiempo de compilación
@Mapper(componentModel = "spring",
        unmappedTargetPolicy = ReportingPolicy.ERROR)   // ← la clave: falla si olvidas uno
interface PedidoMapper {
    @Mapping(target = "numeroLineas", expression = "java(p.getLineas().size())")
    @Mapping(target = "estado", source = "estado")
    PedidoResponse aResponse(Pedido p);
    List<PedidoResponse> aResponses(List<Pedido> ps);
}

Lo que hay que evitar es ModelMapper y los mapeadores por reflexión en tiempo de ejecución: son cómodos al principio y una fuente de bugs después, porque un renombrado deja el campo a null sin que nada falle ni en compilación ni en los tests, y cuestan rendimiento en cada llamada. Esa es la comparación que se busca: compilación frente a ejecución, error temprano frente a null silencioso.

Trampa: con MapStruct y entidades JPA, un mapeo que recorre relaciones perezosas puede disparar un N+1 escondido dentro del mapeador. Mapea desde proyecciones o desde entidades cargadas con @EntityGraph, y comprueba las consultas con un test que las cuente.

Otro proxy: intercepta la llamada, calcula una clave, mira en la caché y solo ejecuta el método si no está. Requiere @EnableCaching. La implementación por defecto en Boot es un mapa concurrente sin límite — que es una fuga de memoria—, así que en la práctica se usa Caffeine (local) o Redis (distribuida).

@Service
class ServicioTarifas {

    @Cacheable(cacheNames = "tarifas", key = "#pais + ':' + #tipo",
               unless = "#result == null")                 // no cachear nulos
    Tarifa buscar(String pais, String tipo) { ... }

    @CachePut(cacheNames = "tarifas", key = "#t.clave()")   // actualiza sin leer
    Tarifa guardar(Tarifa t) { ... }

    @CacheEvict(cacheNames = "tarifas", key = "#clave")
    void borrar(String clave) { }

    @CacheEvict(cacheNames = "tarifas", allEntries = true)
    void recargarTodo() { }
}

spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=10000,expireAfterWrite=10m,recordStats

Las trampas, que son la parte interesante de la respuesta:

• Autoinvocación: igual que @Transactional. Llamar al método cacheado desde la misma clase se salta el proxy y la caché no se usa.
• Clave por defecto: son todos los parámetros. Si uno es una entidad con hashCode mutable o un objeto grande, la clave es un desastre. Define siempre la clave con SpEL.
• Invalidación olvidada: el bug más frecuente. Alguien actualiza el dato por otra vía (una migración, otro servicio, un UPDATE manual) y la caché sirve datos viejos indefinidamente. Sin TTL, «indefinidamente» significa hasta el próximo despliegue.
• Sin límite de tamaño: OutOfMemoryError garantizado con claves de alta cardinalidad (cachear por identificador de usuario, por ejemplo).
• Stampede: cuando expira una clave muy solicitada, mil peticiones simultáneas recalculan lo mismo. Se mitiga con sync = true (que bloquea en local) o con refresco asíncrono.
• Excepciones y caché: si el método lanza, no se cachea nada; pero si devuelve un valor «vacío» por un fallo, cachearás el fallo. Ojo con unless.
• Varias instancias: con caché local, cada pod tiene datos distintos y una invalidación en uno no llega a los demás. Hay que decidir si eso es tolerable.

Trampa: la pregunta de seguimiento suele ser «¿qué cachearías?». La respuesta con criterio: datos que se lean mucho, cambien poco y toleren estar un poco desactualizados, con TTL corto y tamaño máximo. Nunca datos de autorización ni saldos ni stock, donde un valor viejo tiene consecuencias.

Para operar la aplicación: salud, métricas, información de configuración y diagnóstico. Y la parte importante de la respuesta es la de seguridad: Actuator abierto es una de las fugas de información más comunes en aplicaciones Spring.

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,prometheus     # lista blanca explícita
      base-path: /actuator
  server:
    port: 8081                     # ← puerto SEPARADO, no expuesto al exterior
  endpoint:
    health:
      show-details: when-authorized
      probes:
        enabled: true              # /health/liveness y /health/readiness
  health:
    livenessstate.enabled: true
    readinessstate.enabled: true
  metrics:
    tags:
      application: ${spring.application.name}
  tracing:
    sampling:
      probability: 0.1

Los health groups son la clave para Kubernetes: liveness debe comprobar solo que el proceso está vivo y readiness las dependencias necesarias para atender tráfico. Si metes la base de datos en liveness, un corte de base de datos hace que Kubernetes reinicie todos los pods en bucle, convirtiendo una degradación en una caída total. Ese es el error arquitectónico que la pregunta busca.

// Un indicador de salud propio, para una dependencia crítica
@Component
class PasarelaHealthIndicator implements HealthIndicator {
    @Override public Health health() {
        try {
            var ms = pasarela.ping();
            return Health.up().withDetail("latenciaMs", ms).build();
        } catch (Exception e) {
            return Health.down(e).withDetail("proveedor", "stripe").build();
        }
    }
}

Trampa: /actuator/env, /actuator/configprops, /actuator/heapdump y /actuator/threaddump exponen configuración, cadenas de conexión y hasta el contenido de la memoria. Nunca deben ser accesibles desde internet. Y include: "*" en producción es un hallazgo directo en cualquier auditoría.

Con Micrometer, que es la fachada de métricas de Spring (el equivalente a SLF4J para logs), y exportando a Prometheus. Lo importante no es la herramienta, es qué mides: las cuatro señales de oro más las métricas de negocio.

@Service
class ServicioPedidos {
    private final Counter creados;
    private final Timer tiempoCobro;

    ServicioPedidos(MeterRegistry registry) {
        this.creados = Counter.builder("pedidos.creados")
                .description("Pedidos creados correctamente")
                .tag("canal", "web")
                .register(registry);
        this.tiempoCobro = Timer.builder("pedidos.cobro")
                .publishPercentiles(0.5, 0.95, 0.99)
                .register(registry);
    }

    Pedido crear(CrearPedido cmd) {
        return tiempoCobro.record(() -> { var p = hacer(cmd); creados.increment(); return p; });
    }
}
// @Timed y @Counted en el método también funcionan (por AOP), con las limitaciones
// habituales del proxy.

Trampa: cardinalidad. Poner como etiqueta el identificador de usuario, el de pedido o la URL con parámetros crea millones de series temporales y tumba Prometheus. Las etiquetas deben tener pocos valores posibles (endpoint, método, estado, canal). Es un error muy común y muy caro, y mencionarlo demuestra experiencia real de operación.

MVC con hilos virtuales para casi todo. La razón principal por la que se adoptaba WebFlux —no bloquear hilos de plataforma en llamadas de I/O— ya está resuelta desde Java 21 con código bloqueante normal, que es muchísimo más fácil de escribir, leer y depurar.

Cuándo sí elegiría WebFlux: puertas de enlace y agregadores con muchísimas conexiones concurrentes y poca lógica, streaming real, sistemas que necesitan contrapresión de punta a punta, y proyectos donde el equipo ya domina Reactor y el resto del stack es reactivo. Cuándo no: una API REST con JPA. Mezclar los dos modelos —bloquear dentro de un flujo reactivo— es lo peor de ambos mundos y una fuente de incidentes muy difíciles de diagnosticar.

Trampa: si dices «WebFlux es más rápido», te van a pedir el número. La verdad es que en throughput con carga moderada son comparables, y que WebFlux gana en memoria y en número de conexiones simultáneas sostenidas. La respuesta que suena a experiencia es: «no elegiría por rendimiento, elegiría por el modelo de programación y por lo que el equipo puede mantener».

Es una herramienta para construir monolitos modulares verificables: define los módulos por convención (los paquetes de primer nivel bajo la aplicación), permite verificar con un test que nadie viola los límites, y facilita la comunicación entre módulos por eventos con soporte de persistencia.

// Estructura: cada paquete de primer nivel es un módulo
// com.tienda
//   ├── pedidos      ← API pública del módulo: solo las clases de este paquete
//   │   └── internal ← implementación: inaccesible para otros módulos
//   ├── catalogo
//   └── facturacion

@Test void la_arquitectura_se_respeta() {
    var modulos = ApplicationModules.of(TiendaApplication.class);
    modulos.verify();                 // falla si un módulo accede al internal de otro
    new Documenter(modulos).writeDocumentation();   // genera diagramas C4 y PlantUML
}

// Eventos entre módulos, con reintentos y persistencia (el outbox integrado)
@ApplicationModuleListener            // = @Async + @Transactional + AFTER_COMMIT
void al(PedidoCompletado evento) { facturacion.emitir(evento.pedidoId()); }
// Con spring-modulith-events-jpa, el evento se guarda en una tabla y se reintenta
// si el consumidor falla: resuelve el agujero de @TransactionalEventListener.

Por qué importa en una entrevista de arquitectura: es la respuesta concreta a «monolito modular primero». El argumento clásico contra el monolito modular es que los límites se erosionan porque nada los defiende; Modulith los convierte en un test que falla en el pull request. Y si algún día un módulo tiene que salir a servicio propio, ya está delimitado y ya se comunica por eventos.

Trampa: no es un framework de microservicios ni un sustituto de Kafka. Los eventos siguen siendo internos al proceso (con persistencia y reintentos, pero internos). Confundirlo con integración entre servicios es un error conceptual.

Spring Framework aporta el núcleo: contenedor de inversión de control, AOP, abstracción de transacciones, Spring MVC, la abstracción de acceso a datos. Spring Boot es una capa de opinión encima que elimina la configuración repetitiva.

La frase que resume bien: «Boot no es un framework nuevo, es Spring con convención sobre configuración y con todo lo necesario para producción de serie. Y lo importante es que todas las decisiones se pueden sobrescribir: si defino mi propio bean, la autoconfiguración se aparta.»

Trampa: te pueden preguntar si Boot añade rendimiento. No: añade productividad y estandarización. El rendimiento en tiempo de ejecución es el de Spring Framework; lo que Boot ha mejorado mucho en las últimas versiones es el arranque (menos proxies con proxyBeanMethods = false, más condiciones evaluadas sin cargar clases, y soporte de AOT y de imagen nativa).

JPA es la especificación (anotaciones e interfaces: EntityManager, @Entity). Hibernate es la implementación más usada: traduce objetos a SQL, gestiona el contexto de persistencia, la caché de primer nivel y las estrategias de carga.

En Spring Data JPA usas repositorios; debajo sigue habiendo un EntityManager y una sesión de Hibernate. Si no entiendes esa capa, N+1 y LazyInitializationException parecen magia negra.

Trampa: decir «JPA es Hibernate» pierde precisión; son capa y motor.

Estados: transient (nueva, no gestionada), managed (en el contexto, los cambios se sincronizan), detached (tuvo id pero ya no está en el contexto) y removed (marcada para borrado).

Solo las managed se flush-ean automáticamente. Un DTO no es una entidad; un save sobre detached puede hacer merge o insert según tenga id.

Con spring.jpa.open-in-view=true (por defecto) la sesión permanece abierta durante el renderizado HTTP. Eso oculta N+1 (las relaciones se cargan al serializar) y mantiene conexiones del pool ocupadas más tiempo.

Lo correcto: desactivarlo, cargar lo necesario en el servicio (fetch join, entity graph o proyección) y devolver DTOs. Si aparece LazyInitializationException, es una señal útil: faltaba una carga explícita.

Trampa: «lo dejo activado porque es más cómodo» es una bandera roja en senior.

Una consulta trae N padres; al tocar una relación lazy se dispara 1 consulta por padre. Se detecta logueando SQL o contando statements en test.

Arreglos: join fetch / @EntityGraph, @BatchSize / default_batch_fetch_size, o proyección DTO/JdbcTemplate cuando no necesitas entidades.

// Mal: findAll() + getLineas() en un bucle
// Bien:
@Query("select p from Pedido p join fetch p.lineas where p.estado = :e")
List<Pedido> findConLineas(Estado e);

Trampa: fetch join + paginación (Pageable) puede duplicar filas; usa ventana o dos consultas.

Lazy por defecto en @ManyToOne/@OneToMany (en JPA 2+ ManyToOne es Eager por defecto — conviene forzarlo a Lazy). Eager carga siempre, aunque no uses la relación: peor en listados.

Regla: todo lazy; carga explícita cuando el caso de uso lo pide. Eager global es la causa número uno de consultas explosivas.

1er nivel: el contexto de persistencia (sesión). Misma entidad por id = misma instancia dentro de la transacción. Obligatoria.

2º nivel: compartida entre sesiones (p. ej. Ehcache/Infinispan). Útil para catálogos estables; peligrosa con datos mutables y en clúster sin invalidación correcta. No es un sustituto de Redis de aplicación.

Optimista: columna @Version; al conflictar, OptimisticLockException → 409. No bloquea filas.

Pesimista: LockModeType.PESSIMISTIC_WRITE (SELECT … FOR UPDATE) en secciones cortas. Optimista por defecto; pesimista si la colisión es frecuente y la sección es breve.

Trampa: olvidar @Version en entidades concurrentes es un clásico.

Flyway o Liquibase: scripts versionados en el repo, aplicados en orden, ddl-auto=validate (nunca update en prod). Cambios compatibles hacia atrás en dos fases para despliegues sin downtime.

Nunca editar una migración ya aplicada; crear una nueva. En entrevista, menciona rollback/forward-only y datos de seed aparte.

persist: transient → managed; falla si ya tiene id gestionado de otra forma. merge: copia estado de detached a managed y devuelve la managed.

Spring Data save: si el id es null (o isNew), persist; si no, merge. Por eso un id asignado a mano puede hacer merge inesperado.

Reporting pesado, UPSERT masivos, CTEs complejas, bulk updates, o cuando el SQL es el producto. Ahí: JdbcTemplate, jOOQ o SQL nativo.

JPA brilla en el modelo transaccional de escritura del dominio; no es obligatorio para cada SELECT del sistema.

Habla en voz alta del plan: filtrar por fecha e importe, agrupar por cliente, ordenar, limitar. Menciona índice en (fecha, importe) o al menos en fecha.

SELECT c.id, c.nombre, SUM(p.importe) AS total
FROM pedidos p
JOIN clientes c ON c.id = p.cliente_id
WHERE p.fecha >= CURRENT_DATE - INTERVAL '1 month'
  AND p.importe > 100
GROUP BY c.id, c.nombre
ORDER BY total DESC
LIMIT 10;

Trampa: en Oracle/SQL Server el dialecto de fechas/límite cambia; dilo.

Estructura (B-tree habitual) que acelera filtros y joins a costa de espacio y de escrituras más lentas. Ayuda si la selectividad es alta y la consulta lo usa (cubre o busca y luego lookup).

Duele: índices no usados, duplicados, en columnas de baja cardinalidad solas, o demasiados en tablas de escritura intensa. EXPLAIN (ANALYZE) manda.

READ COMMITTED (Postgres por defecto): no lees sucio; puedes ver no-repetible. REPEATABLE READ / Snapshot evitan no-repetible. SERIALIZABLE evita anomalías de escritura concurrente con reintentos.

Lectura fantasma: una misma query ve filas nuevas insertadas por otra transacción entre dos lecturas. En RR de Postgres el snapshot lo evita para muchas anomalías.

Traer solo las columnas necesarias a un record/interfaz, sin entidad completa ni grafo. Evita lazy surprises, reduce I/O y aclara el contrato del caso de uso.

Con Spring Data: interfaces cerradas, Class-based projections o @Query con constructor expression.

REQUIRED (default): se une a la existente o abre una. REQUIRES_NEW: suspende la actual y abre otra; su commit/rollback es independiente.

Útil para auditar un fallo aunque la operación padre revierta. Coste: más conexiones y riesgo de inconsistencia de negocio si se abusa.

Trampa: llamar a @Transactional desde la misma clase no pasa por el proxy.

Offset (LIMIT/OFFSET) es simple y se degrada en páginas profundas. Keyset/seek (WHERE id > :last ORDER BY id LIMIT n) escala mejor.

Nunca paginar en memoria tras un findAll. Con fetch join, cuidado con el conteo de Page.

Equipo pequeño, dominio poco entendido, sin CI/CD ni observabilidad, o cuando la mayoría de operaciones necesitan consistencia fuerte entre partes.

Un monolito modular (p. ej. Spring Modulith) da límites claros sin el coste de red, latencia y ops. Microservicios son una consecuencia del tamaño organizativo, no un premio.

Trampa: «siempre microservicios porque escalan» es respuesta junior.

En DDD, un límite donde un modelo tiene un significado coherente. «Cliente» en facturación no es el mismo que en marketing.

Entre contextos: traducción explícita (anti-corruption layer), no un único modelo compartido. En microservicios, un servicio ≈ un contexto (idealmente).

Consistencia eventual: cada servicio es dueño de sus datos; eventos para propagar hechos; outbox/CDC para no perderlos; consumidores idempotentes; sagas con compensación para flujos multipaso.

Evita 2PC distribuido en el día a día: frágil y acopla disponibilidad.

En la misma transacción local guardas el cambio de negocio y el evento en tabla outbox. Un publicador (polling o Debezium) lo envía al broker.

Resuelve el agujero «commit en DB + publish a Kafka» que no es atómico. Menciona idempotencia en el consumidor.

Coreografía: cada servicio reacciona a eventos; menos punto central, más difícil de seguir. Orquestación: un coordinador dirige pasos; más visible, riesgo de dios-orquestador.

Elige según complejidad del flujo y necesidad de visibilidad. Siempre define compensaciones.

Cerrado → cuenta fallos; Abierto → falla rápido + fallback; Semiabierto → pruebas. Evita cascadas cuando una dependencia está enferma.

No sustituye timeouts ni bulkheads. Sin métricas y alertas, el breaker es teatro.

Repetir la operación deja el mismo efecto que una vez. Clave de idempotencia almacenada, Upsert natural, o deduplicación por id de mensaje.

Imprescindible con at-least-once (Kafka, reintentos HTTP).

Entrada única: TLS, authn gruesa, rate limit, enrutado, a veces agregación. No debe contener lógica de negocio profunda ni ser el único sitio de autorización fina (IDOR se arregla en el servicio).

Evolución compatible: campos nuevos opcionales, no reutilizar significados. Versionado por URL (/v2) o cabecera cuando el breaking es inevitable. Deprecación anunciada y métricas de uso.

R/R: simple, inmediato, acopla temporalmente. Eventos: desacoplan, escalan lectores, complican consistencia y depuración.

Híbrido habitual: comando síncrono para la decisión del usuario; eventos para fan-out.

Ante partición de red, eliges consistencia o disponibilidad. En la práctica diseñas por caso de uso: saldo/caja → C; timeline social → A+eventual.

No es un eslogan para justificar Kafka: es una pregunta de requisitos.

Logs (estructurados, correlation id), métricas (RED/USE), trazas distribuidas (traceId entre servicios). Sin eso, microservicios son una caja negra cara.

Consumer-driven contracts, OpenAPI/AsyncAPI publicados, esquemas Avro/JSON Schema en registro. Romper un contrato es un cambio de producto, no un detalle de implementación.

Anti-patrón: una DB compartida acopla despliegues y modelos. Preferible: API/eventos y réplicas de lectura propias si hace falta. «Shared database» solo como paso temporal consciente.

Dominio en el centro; puertos (interfaces); adapters (JPA, REST, mensajería). Facilita tests y cambiar infraestructura.

En Spring: paquetes por feature, dominio sin anotaciones web, repositorios detrás de interfaces.

Rate limit protege capacidad; bulkhead aísla pools para que un vecino lento no agote todos los hilos/conexiones. Con virtual threads sigue haciendo falta limitar el recurso escaso (DB, API externa).

Multi-stage o bootBuildImage/Buildpacks: JRE mínimo o runtime jlink, usuario no root, capas de dependencias cacheables, sin secretos ni herramientas de debug en prod.

Healthchecks alineados con Actuator. Distroless o alpine solo si conoces los trade-offs de libc/DNS.

Liveness: proceso vivo (reiniciar si falla). Readiness: ¿acepto tráfico? (sacar del balanceador si la DB no está lista). Mezclarlos provoca reinicios en bucle durante degradaciones.

Config por entorno (vars, secretos del orquestador), no por WAR recompilado. Perfiles Spring sí; credenciales en Git nunca. Menciona Externalized Config y rotación.

Build + test + análisis (SpotBugs/Checkstyle) + SCA de dependencias + imagen firmada + deploy a staging. Fallar el pipeline ante CVE HIGH/CRITICAL y secretos detectados.

Vault/Secrets Manager/SOPS + inyección en runtime. Nunca en imágenes ni en logs. Rotación y principio de mínimo privilegio en roles IAM/K8s.

Deployment: pods intercambiables (APIs). StatefulSet: identidad estable y disco (brokers, DB). La mayoría de microservicios stateless van en Deployment + PVC solo si realmente hace falta.

Injection: parámetros enlazados, nunca concatenar SQL. Broken access control: checks en servicio + ownership en query. Security misconfig: Actuator expuesto, CORS abierto, defaults de seguridad desactivados.

Firma y algoritmo (deny list none), exp/nbf, iss, aud, kid. Un JWT no revoca solo: diseña TTL cortos + refresh/denylist si hace falta.

Trampa: olvidar aud es el fallo más citado.

OAuth2 autoriza acceso a recursos; OIDC autentica identidad (id_token). Para apps: Authorization Code + PKCE.

Inventario de dependencias (CycloneDX/Syft), escaneo (Trivy/Grype), firma (cosign) y políticas de admisión. Tú escribes poco del binario que ejecutas.

Error rate, latencia p95/p99, saturación (CPU, pool DB, cola), logs con traceId, y comparación con baseline. Rollback criterion definido antes del deploy.

Blue/green: dos entornos, corte rápido, rollback simple, más coste. Canary: % de tráfico, detecta regresiones con menos blast radius, necesita métricas buenas.

Autorización por objeto: la query filtra por usuario/tenant (where id=:id and owner=:user). Tests de acceso cruzado. No confiar solo en ocultar el id en la UI.

S: En un Black Friday el p95 de checkout pasó de 200 ms a 4 s. T: Yo era el on-call del servicio de precios. A: Congelé el deploy, miré trazas (el 80 % del tiempo estaba en un N+1 nuevo), revertí el PR, añadí test que cuenta SQL y una alerta de p95. R: Recuperamos en 25 minutos; el postmortem cambió la checklist de PR. Aprendí que un benchmark local no sustituye un test de consultas.