En Spring Security 6, `WebSecurityConfigurerAdapter` ya no existe: la configuración se declara como un bean `SecurityFilterChain`.

Verdadero. Se marcó como obsoleto en 5.7 y se eliminó en 6.0.

Un JWT firmado está cifrado: nadie puede leer su contenido sin la clave.

Falso. La cabecera y el payload son Base64URL: cualquiera puede leerlos. La firma solo garantiza que no se han alterado. Nunca pongas secretos en un JWT.

En una API stateless con JWT, el servidor guarda la sesión de cada usuario en memoria.

Falso. Cada petición trae su token y se valida por sí misma. Precisamente por eso la API puede escalar a varias instancias sin sesión compartida.

BCrypt usa una sal aleatoria, así que la misma contraseña genera hashes distintos cada vez.

Verdadero. La sal va guardada dentro del propio hash, y `matches()` la usa para comprobar la contraseña.

Para que `@PreAuthorize` funcione hay que activar la seguridad a nivel de método con `@EnableMethodSecurity`.

Verdadero. Sin esa anotación, `@PreAuthorize` se ignora sin dar ningún error.

Los virtual threads hacen que el código que consume mucha CPU vaya más rápido.

Falso. Ayudan cuando los hilos pasan mucho tiempo esperando I/O. Con trabajo de CPU el límite siguen siendo los núcleos.

En Java 21, un virtual thread que se bloquea dentro de un bloque `synchronized` puede quedar anclado (pinning) a su carrier thread.

Verdadero. Mientras está anclado no libera el hilo de plataforma. JDK 24 lo resolvió con la JEP 491, pero en Java 21 conviene usar `ReentrantLock`.

En Spring Boot 3.2 o superior, `spring.threads.virtual.enabled=true` hace que las peticiones se atiendan con virtual threads.

Verdadero. Afecta a Tomcat, a `@Async` y a varios ejecutores. Requiere Java 21.

En Project Reactor, un `Flux` normal no emite nada hasta que alguien se suscribe.

Verdadero. Los publishers son perezosos ("cold"): declarar la cadena no ejecuta nada hasta el `subscribe()`, que en WebFlux hace el framework.

Llamar a un método bloqueante dentro de un pipeline de WebFlux no tiene consecuencias.

Falso. WebFlux usa muy pocos hilos de event loop. Bloquear uno frena todas las peticiones que dependen de él. Ese trabajo va en `Schedulers.boundedElastic()`.

`volatile` hace que `contador++` sea atómico.

Falso. `volatile` garantiza que los hilos ven la última escritura, pero `contador++` son tres pasos (leer, sumar y escribir) que pueden intercalarse. Hace falta `AtomicInteger` o un lock.

En un `ConcurrentHashMap`, `if (!map.containsKey(k)) map.put(k, v)` es seguro porque cada operación es atómica.

Falso. Cada operación por separado es segura, pero entre las dos otro hilo puede insertar la clave. Hay que usar `putIfAbsent` o `computeIfAbsent`, que lo hacen en un solo paso.

Si no pasas un executor, `CompletableFuture.supplyAsync` usa el `ForkJoinPool.commonPool()`.

Verdadero. Es el pool común de la JVM, compartido también por los parallel streams y dimensionado para tareas de CPU. Para llamadas de red conviene pasar un executor propio.

Después de `thread.join()` ves todo lo que escribió ese hilo antes de terminar.

Verdadero. El Java Memory Model establece una relación happens-before entre todo lo que hace un hilo y el retorno de `join()` sobre él.

Quiz de la fase 4 Fase 4: Seguridad, Concurrencia y Reactividad vs Virtual Threads

¿Verdadero o falso?

14 afirmaciones sobre los días de esta fase. Responde cada una y lee la explicación: el fallo suele estar en un matiz.

0 de 14 respondidas
0 aciertos

En Spring Security 6, WebSecurityConfigurerAdapter ya no existe: la configuración se declara como un bean SecurityFilterChain.
Un JWT firmado está cifrado: nadie puede leer su contenido sin la clave.
En una API stateless con JWT, el servidor guarda la sesión de cada usuario en memoria.
BCrypt usa una sal aleatoria, así que la misma contraseña genera hashes distintos cada vez.
Para que @PreAuthorize funcione hay que activar la seguridad a nivel de método con @EnableMethodSecurity.
Los virtual threads hacen que el código que consume mucha CPU vaya más rápido.
En Java 21, un virtual thread que se bloquea dentro de un bloque synchronized puede quedar anclado (pinning) a su carrier thread.
En Spring Boot 3.2 o superior, spring.threads.virtual.enabled=true hace que las peticiones se atiendan con virtual threads.
En Project Reactor, un Flux normal no emite nada hasta que alguien se suscribe.
Llamar a un método bloqueante dentro de un pipeline de WebFlux no tiene consecuencias.
volatile hace que contador++ sea atómico.
En un ConcurrentHashMap, if (!map.containsKey(k)) map.put(k, v) es seguro porque cada operación es atómica.
Si no pasas un executor, CompletableFuture.supplyAsync usa el ForkJoinPool.commonPool().
Después de thread.join() ves todo lo que escribió ese hilo antes de terminar.