Senior Java Backend — Preguntas de entrevista Java backend

¿Cómo diagnosticarías una fuga de memoria en un servicio JVM de larga duración?

Primero confirma que es una fuga: observa el heap después de un GC completo durante horas, ya que un patrón de sierra que vuelve a la línea base no es una fuga. Luego toma un heap dump y ábrelo en MAT, que nombra el dominator tree — los objetos que retienen más memoria y quién los referencia. Las respuestas usuales son un caché sin límite, un ThreadLocal nunca limpiado en un hilo pooleado, o listeners que se registran y nunca se desregistran.

¿Cuándo elegirías Saga sobre una transacción distribuida?

Casi siempre, porque el commit de dos fases necesita que cada participante lo soporte y mantiene locks a través de la red, lo que acopla la disponibilidad de todos los servicios al más lento. Una Saga secuencia transacciones locales con acciones compensatorias, así que cada servicio hace commit independientemente y un fallo dispara un deshacer. El costo es que tienes que diseñar las compensaciones, y hay estados donde un externo puede observar una completitud parcial.

¿Qué cambia Project Loom sobre cómo escribes código concurrente?

Los hilos virtuales hacen el bloqueo barato: un hilo estacionado en IO ya no retiene un hilo del SO, así que el modelo de un hilo por request escala sin plomería reactiva. La consecuencia práctica es que las cadenas de CompletableFuture y los stacks reactivos adoptados puramente para evitar el bloqueo pierden su razón de existir. Lo que no cambia es que los bloques synchronized pueden fijar un hilo virtual, y los pools de hilos dimensionados para hilos del SO se vuelven la abstracción equivocada.

¿Cómo decides entre ajustar el GC y arreglar la asignación?

Mide primero la tasa de asignación. Si la aplicación asigna gigabytes por segundo, ningún ajuste de colector la salvará y el arreglo está en el código — churn de objetos en un loop caliente, boxing, copias defensivas. El ajuste de GC es la palanca correcta cuando la asignación es razonable pero las pausas fallan tu objetivo de latencia, y entonces la elección suele ser G1 con un pause goal, o ZGC cuando el heap es lo bastante grande como para que ni G1 pueda seguirle el ritmo.

Un equipo quiere dividir el monolito en microservicios. ¿Qué preguntas antes de aceptar?

Qué problema resuelve eso que un límite de módulo no puede. Deploys independientes y escalado independiente son respuestas reales; "los microservicios son modernos" no lo es. Luego si pueden manejar datos distribuidos — sin joins entre servicios, consistencia eventual, y una Saga para cualquier cosa que antes era una sola transacción. Y si ops puede soportarlo, porque diez servicios con un solo pipeline y sin tracing es peor que el monolito.

¿Cómo mantienes un codebase grande de Java actualizable a través de versiones LTS?

Mantén las dependencias cerca de lo actual continuamente en lugar de en un proyecto de big-bang — el costo crece superlinealmente según cuán atrás estés. Evita la reflexión hacia los internos del JDK, ya que eso es lo que se rompe bajo la encapsulación de módulos. Ten una suite de tests en la que confíes lo suficiente como para creer en una corrida verde, y actualiza en una rama que compile contra ambas versiones para que la migración sea revisable en vez de un precipicio.