# Spring Boot 3.4 Virtual Threads: Preguntas de Entrevista y Benchmarks de Rendimiento

> Domina los Virtual Threads de Java 21 con Spring Boot 3.4: 15 preguntas de entrevista, benchmarks de rendimiento y patrones de migración para superar las entrevistas técnicas.

- Published: 2026-03-15
- Updated: 2026-05-01
- Author: SharpSkill
- Tags: spring boot, virtual threads, java 21, project loom, performance
- Reading time: 16 min

---

Los Virtual Threads representan uno de los avances más significativos de Java 21, y Spring Boot 3.4 los integra de forma nativa. Esta característica del Project Loom transforma la gestión de la concurrencia en aplicaciones backend. Las entrevistas técnicas evalúan ahora la comprensión de los mecanismos internos, los casos de uso adecuados y los errores comunes que conviene evitar.

> **Consejo de Preparación**
>
> Los entrevistadores distinguen a los candidatos que comprenden los Virtual Threads de aquellos que los usan a ciegas. Saber cuándo NO utilizarlos es tan importante como conocer sus beneficios.

## Fundamentos de los Virtual Threads

### Pregunta 1: ¿Qué es un Virtual Thread y en qué se diferencia de un Platform Thread?

Un Virtual Thread es un hilo ligero gestionado por la JVM en lugar del sistema operativo. A diferencia de los Platform Threads (hilos tradicionales), los Virtual Threads no se mapean directamente a hilos del SO. La JVM puede crear millones de ellos con un consumo mínimo de memoria.

```java
// VirtualThreadDemo.java
// Comparing thread creation approaches
public class VirtualThreadDemo {

    public void demonstrateDifference() {
        // Platform Thread: ~1MB stack per thread
        // Practical limit: a few thousand on a standard JVM
        Thread platformThread = new Thread(() -> {
            performBlockingOperation();
        });

        // Virtual Thread: ~a few KB per thread
        // Can create millions without issues
        Thread virtualThread = Thread.ofVirtual().start(() -> {
            performBlockingOperation();
        });
    }

    // A Virtual Thread "mounts" onto a Platform Thread (carrier)
    // During I/O blocking, it releases the carrier for other Virtual Threads
    private void performBlockingOperation() {
        try {
            Thread.sleep(1000); // Virtual Thread detaches from carrier here
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}
```

La diferencia fundamental reside en el comportamiento ante el bloqueo. Cuando un Platform Thread se bloquea (E/S, sleep), permanece adherido al hilo del SO. Un Virtual Thread se "desmonta" del hilo portador, permitiendo que otros Virtual Threads utilicen ese carrier.

### Pregunta 2: ¿Cómo activar los Virtual Threads en Spring Boot 3.4?

Spring Boot 3.4 simplifica la activación de los Virtual Threads a una única propiedad de configuración. El framework completo se adapta automáticamente: Tomcat, los controladores REST y las llamadas bloqueantes se benefician de inmediato de esta optimización.

```yaml
# application.yml
# Global Virtual Threads activation
spring:
  threads:
    virtual:
      enabled: true

# Optional Tomcat pool configuration
server:
  tomcat:
    threads:
      max: 200  # Less critical with Virtual Threads
      min-spare: 10
```

```java
// WebConfig.java
// Programmatic activation if needed
@Configuration
public class WebConfig {

    @Bean
    public TomcatProtocolHandlerCustomizer<?> virtualThreadCustomizer() {
        // Each HTTP request runs on a Virtual Thread
        return protocolHandler -> {
            protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
        };
    }
}
```

La activación cambia el comportamiento de Tomcat: en lugar de un pool de hilos fijo, cada petición obtiene su propio Virtual Thread. Este enfoque elimina el cuello de botella tradicional del pool de hilos.

### Pregunta 3: Explica el concepto de "mounting" y "unmounting"

El mounting designa la unión de un Virtual Thread a un hilo portador (Platform Thread). El unmounting ocurre durante las operaciones bloqueantes y libera el carrier para otros Virtual Threads. Este mecanismo permite un uso óptimo de los recursos de CPU.

```java
// MountingDemo.java
// Illustrating the mounting/unmounting cycle
public class MountingDemo {

    public void demonstrateMounting() {
        Thread.ofVirtual().start(() -> {
            // MOUNTED: Virtual Thread is using a carrier thread
            System.out.println("Carrier: " + getCurrentCarrier());

            // UNMOUNTING: releases carrier during blocking
            performDatabaseQuery(); // Blocking JDBC call

            // REMOUNTED: may be on a different carrier
            System.out.println("New carrier: " + getCurrentCarrier());
        });
    }

    // Blocking operations trigger unmounting automatically
    private void performDatabaseQuery() {
        // JDBC connection, file read, network call...
        // Virtual Thread detaches during I/O wait
    }

    private String getCurrentCarrier() {
        // Gets the current carrier thread name
        return Thread.currentThread().toString();
    }
}
```

Este mecanismo resulta transparente para el desarrollador. El código se escribe en estilo imperativo clásico, pero la JVM optimiza automáticamente el uso de los carriers. Un pool de unos pocos carriers puede atender a millones de Virtual Threads.

> **Nota Técnica**
>
> El número de hilos portadores se corresponde por defecto con el número de núcleos de CPU. La JVM ajusta este pool dinámicamente mediante el ForkJoinPool.

## Casos de Uso y Antipatrones

### Pregunta 4: ¿Cuándo aportan los Virtual Threads ganancias de rendimiento?

Los Virtual Threads brillan en cargas dominadas por E/S: llamadas REST externas, consultas a bases de datos, lecturas de archivos. Estas operaciones pasan la mayor parte del tiempo en espera, intervalo durante el cual el Virtual Thread libera su carrier.

```java
// IOBoundService.java
// Ideal case for Virtual Threads
@Service
public class IOBoundService {

    private final RestClient restClient;
    private final UserRepository userRepository;

    // Each call involves network and database waiting
    // Virtual Threads shine here
    public UserProfile enrichUserProfile(Long userId) {
        // DB call - VT detaches during SQL query
        User user = userRepository.findById(userId).orElseThrow();

        // External REST call - VT detaches during HTTP wait
        ExternalData externalData = restClient
            .get()
            .uri("/api/external/{id}", userId)
            .retrieve()
            .body(ExternalData.class);

        // Data aggregation
        return new UserProfile(user, externalData);
    }
}
```

La ganancia procede del manejo de un mayor número de peticiones concurrentes. Con 200 Platform Threads y peticiones de 100 ms, el throughput máximo es de 2.000 req/s. Con Virtual Threads, esa cifra puede alcanzar más de 50.000 req/s en la misma máquina.

### Pregunta 5: ¿Qué antipatrones conviene evitar con los Virtual Threads?

Los Virtual Threads no resultan adecuados para cargas CPU-bound ni para casos que provoquen "pinning". El pinning aparece cuando un Virtual Thread permanece adherido a su carrier a pesar del bloqueo, anulando los beneficios de la virtualización.

```java
// AntiPatterns.java
// Examples of cases to avoid
@Service
public class AntiPatterns {

    // ANTI-PATTERN 1: CPU-intensive computation
    // Virtual Threads provide no benefit here
    public BigInteger computeFactorial(int n) {
        // 100% CPU, no I/O, no unmounting possible
        BigInteger result = BigInteger.ONE;
        for (int i = 2; i <= n; i++) {
            result = result.multiply(BigInteger.valueOf(i));
        }
        return result; // Carrier is monopolized throughout
    }

    // ANTI-PATTERN 2: Synchronized causes pinning
    private final Object lock = new Object();

    public void pinnedOperation() {
        synchronized (lock) { // PINNING: VT stays on carrier
            performDatabaseQuery(); // Unmounting doesn't happen!
        }
    }

    // SOLUTION: Use ReentrantLock
    private final ReentrantLock reentrantLock = new ReentrantLock();

    public void unpinnedOperation() {
        reentrantLock.lock();
        try {
            performDatabaseQuery(); // Unmounting possible
        } finally {
            reentrantLock.unlock();
        }
    }
}
```

El pinning convierte un Virtual Thread en un Platform Thread desde el punto de vista de los recursos. Las causas principales son los bloques `synchronized` y las llamadas nativas JNI. La migración a `ReentrantLock` resuelve el primer caso.

### Pregunta 6: ¿Cómo detectar el pinning en una aplicación?

La JVM ofrece opciones de diagnóstico para identificar los casos de pinning. Esta información resulta esencial al migrar a Virtual Threads, ya que el pinning puede degradar el rendimiento en lugar de mejorarlo.

```java
// PinningDiagnostics.java
// Configuration and pinning detection
public class PinningDiagnostics {

    // JVM option to log pinning
    // -Djdk.tracePinnedThreads=full (detailed)
    // -Djdk.tracePinnedThreads=short (summary)

    // Example code causing pinning
    public void demonstratePinning() {
        Thread.ofVirtual().start(() -> {
            synchronized (this) {
                // This log will appear with tracePinnedThreads enabled
                try {
                    Thread.sleep(100); // Pinned during sleep!
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                }
            }
        });
    }
}
```

```bash
# Typical output with -Djdk.tracePinnedThreads=full
Thread[#23,VirtualThread[#1]/runnable@ForkJoinPool-1-worker-1,5,CarrierThreads]
    java.base/java.lang.VirtualThread$VThreadContinuation.onPinned(VirtualThread.java:183)
    java.base/java.lang.VirtualThread.parkOnCarrierThread(VirtualThread.java:661)
    com.example.PinningDiagnostics.demonstratePinning(PinningDiagnostics.java:15)
```

El análisis de los logs de pinning revela los puntos calientes que conviene corregir. Una aplicación con pinning frecuente no aprovecha los Virtual Threads en su totalidad y puede incluso resultar más lenta que con Platform Threads.

## Benchmarks de Rendimiento

### Pregunta 7: ¿Qué ganancias de rendimiento cabe esperar de los Virtual Threads?

Los benchmarks muestran mejoras notables en aplicaciones I/O-bound típicas. Las ganancias dependen de la relación entre tiempo de E/S y tiempo de CPU, así como del nivel de concurrencia requerido.

```java
// BenchmarkController.java
// Endpoint for measuring performance
@RestController
@RequestMapping("/api/benchmark")
public class BenchmarkController {

    private final ExternalApiClient apiClient;

    // Simulation of a typical endpoint with external calls
    @GetMapping("/user/{id}")
    public ResponseEntity<UserData> getUser(@PathVariable Long id) {
        // Three sequential I/O calls
        UserInfo info = apiClient.fetchUserInfo(id);        // ~50ms
        List<Order> orders = apiClient.fetchOrders(id);     // ~80ms
        CreditScore score = apiClient.fetchCreditScore(id); // ~100ms

        return ResponseEntity.ok(new UserData(info, orders, score));
    }
}
```

```text
# Benchmark results - 10,000 concurrent requests
# Configuration: 8 cores, 16GB RAM, simulated latency 230ms/request

Platform Threads (pool 200):
- Throughput: 850 req/s
- P99 latency: 1250ms
- Heap memory: 2.1GB

Virtual Threads:
- Throughput: 4200 req/s
- P99 latency: 280ms
- Heap memory: 850MB

Gain: 5x throughput, 4.5x P99 latency reduction
```

Los Virtual Threads también reducen el consumo de memoria, ya que cada hilo asigna apenas unos KB en lugar de los aproximadamente 1 MB de un Platform Thread.

### Pregunta 8: ¿Cómo configurar los pools de conexiones con Virtual Threads?

Los pools de conexiones (HikariCP, Lettuce) se convierten en el nuevo cuello de botella con los Virtual Threads. Un pool de 10 conexiones limita a 10 las consultas simultáneas a la base de datos, incluso con millones de Virtual Threads.

```yaml
# application.yml
# HikariCP configuration optimized for Virtual Threads
spring:
  datasource:
    hikari:
      # More connections since Virtual Threads allow more concurrency
      maximum-pool-size: 50
      minimum-idle: 10
      # Shorter timeout due to more concurrent requests
      connection-timeout: 5000
      # Fast validation
      validation-timeout: 3000

  # Redis with Lettuce - already async-friendly
  data:
    redis:
      lettuce:
        pool:
          max-active: 50
          max-idle: 20
```

```java
// ConnectionPoolMonitor.java
// Pool monitoring to avoid contention
@Component
public class ConnectionPoolMonitor {

    private final HikariDataSource dataSource;

    @Scheduled(fixedRate = 10000)
    public void logPoolStats() {
        HikariPoolMXBean pool = dataSource.getHikariPoolMXBean();
        log.info("Pool stats - Active: {}, Idle: {}, Waiting: {}",
            pool.getActiveConnections(),
            pool.getIdleConnections(),
            pool.getThreadsAwaitingConnection());

        // Alert if too many threads waiting
        if (pool.getThreadsAwaitingConnection() > 100) {
            log.warn("Connection pool contention detected!");
        }
    }
}
```

El dimensionamiento del pool depende de la capacidad de la base de datos, no del número de Virtual Threads. Una base PostgreSQL estándar admite del orden de 100-200 conexiones activas.

### Pregunta 9: ¿Cómo medir el impacto de los Virtual Threads con Micrometer?

Micrometer y Spring Boot Actuator aportan métricas esenciales para evaluar la efectividad de los Virtual Threads. Estas métricas validan las ganancias y permiten identificar problemas potenciales.

```java
// VirtualThreadMetrics.java
// Custom metrics for Virtual Threads
@Component
public class VirtualThreadMetrics {

    private final MeterRegistry registry;
    private final AtomicLong activeVirtualThreads = new AtomicLong(0);

    @PostConstruct
    public void registerMetrics() {
        // Active Virtual Threads counter
        Gauge.builder("virtual.threads.active", activeVirtualThreads, AtomicLong::get)
            .description("Number of active virtual threads")
            .register(registry);

        // JVM metrics for carriers
        Gauge.builder("virtual.threads.carriers", this::getCarrierCount)
            .description("Number of carrier threads")
            .register(registry);
    }

    private double getCarrierCount() {
        // Gets the ForkJoinPool carrier count
        return ForkJoinPool.commonPool().getPoolSize();
    }

    // Interceptor to trace requests
    public void trackVirtualThread(Runnable task) {
        activeVirtualThreads.incrementAndGet();
        try {
            task.run();
        } finally {
            activeVirtualThreads.decrementAndGet();
        }
    }
}
```

```yaml
# application.yml
# Metrics exposure
management:
  endpoints:
    web:
      exposure:
        include: health,metrics,prometheus
  metrics:
    tags:
      application: ${spring.application.name}
```

El análisis de las métricas revela la relación Virtual Threads / Carriers e identifica los periodos de contención sobre el pool de conexiones.

## Migración y Compatibilidad

### Pregunta 10: ¿Qué bibliotecas son compatibles con los Virtual Threads?

La compatibilidad depende del uso de bloques `synchronized` y de llamadas nativas. El ecosistema Spring es ampliamente compatible, pero algunas bibliotecas requieren versiones específicas.

```java
// CompatibilityCheck.java
// Checking dependency compatibility
@Configuration
public class CompatibilityCheck {

    // Compatible libraries (recommended versions)
    // - Spring Boot 3.2+ (native support)
    // - HikariCP 5.1+ (ReentrantLock instead of synchronized)
    // - Lettuce 6.3+ (non-blocking I/O)
    // - Jackson 2.16+ (no synchronized)

    // Libraries requiring attention
    // - JDBC drivers: check version
    // - Some legacy HTTP clients

    @Bean
    public CommandLineRunner checkCompatibility() {
        return args -> {
            // Log versions for audit
            log.info("Java version: {}", System.getProperty("java.version"));
            log.info("Virtual threads available: {}",
                Thread.ofVirtual() != null);

            // Support verification
            if (Runtime.version().feature() < 21) {
                throw new IllegalStateException(
                    "Java 21+ required for Virtual Threads");
            }
        };
    }
}
```

La mayoría de los frameworks modernos han migrado a `ReentrantLock`. Para dependencias heredadas, una prueba de carga con `-Djdk.tracePinnedThreads=short` revela los problemas de pinning.

### Pregunta 11: ¿Cómo migrar progresivamente a los Virtual Threads?

Una migración progresiva permite validar las ganancias e identificar problemas sin arriesgar la producción. La estrategia recomendada consiste en aislar los endpoints con Virtual Threads de los tradicionales.

```java
// DualExecutorConfig.java
// Configuration for progressive migration
@Configuration
public class DualExecutorConfig {

    // Traditional executor for legacy endpoints
    @Bean("platformExecutor")
    public ExecutorService platformExecutor() {
        return Executors.newFixedThreadPool(200);
    }

    // Virtual Threads executor for new endpoints
    @Bean("virtualExecutor")
    public ExecutorService virtualExecutor() {
        return Executors.newVirtualThreadPerTaskExecutor();
    }
}

@RestController
@RequestMapping("/api/v2")
public class MigratedController {

    @Qualifier("virtualExecutor")
    private final ExecutorService executor;

    // Endpoint migrated to Virtual Threads
    @GetMapping("/users/{id}")
    public CompletableFuture<User> getUser(@PathVariable Long id) {
        return CompletableFuture.supplyAsync(() -> {
            // Business code unchanged
            return userService.findById(id);
        }, executor);
    }
}
```

```yaml
# application.yml
# Feature flag for migration
features:
  virtual-threads:
    enabled: true
    endpoints:
      - /api/v2/**
      - /api/reports/**

# Disable for quick rollback
# features.virtual-threads.enabled: false
```

> **Atención**
>
> No conviene activar los Virtual Threads de forma global antes de probar todas las dependencias. El pinning puede degradar el rendimiento de manera significativa.

### Pregunta 12: ¿Qué pruebas realizar antes de un despliegue en producción?

La validación de los Virtual Threads exige pruebas de carga, pruebas de pinning y pruebas de compatibilidad. Estas pruebas deben simular condiciones realistas de producción.

```java
// VirtualThreadLoadTest.java
// Load test with JUnit and Virtual Threads
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
class VirtualThreadLoadTest {

    @LocalServerPort
    private int port;

    @Test
    void shouldHandleHighConcurrency() throws Exception {
        int concurrentRequests = 5000;
        CountDownLatch latch = new CountDownLatch(concurrentRequests);
        AtomicInteger successCount = new AtomicInteger(0);
        AtomicInteger errorCount = new AtomicInteger(0);

        HttpClient client = HttpClient.newHttpClient();

        // Launch 5000 simultaneous requests
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < concurrentRequests; i++) {
                executor.submit(() -> {
                    try {
                        HttpRequest request = HttpRequest.newBuilder()
                            .uri(URI.create("http://localhost:" + port + "/api/test"))
                            .build();

                        HttpResponse<String> response = client.send(
                            request, BodyHandlers.ofString());

                        if (response.statusCode() == 200) {
                            successCount.incrementAndGet();
                        } else {
                            errorCount.incrementAndGet();
                        }
                    } catch (Exception e) {
                        errorCount.incrementAndGet();
                    } finally {
                        latch.countDown();
                    }
                });
            }
        }

        latch.await(60, TimeUnit.SECONDS);

        // Performance assertions
        assertThat(successCount.get()).isGreaterThan(4900); // >98% success
        assertThat(errorCount.get()).isLessThan(100);
    }
}
```

Las pruebas deben cubrir escenarios de contención (pool de conexiones saturado), timeouts y carga sostenida durante varios minutos.

## Preguntas Avanzadas

### Pregunta 13: ¿Cómo interactúan los Virtual Threads con la Structured Concurrency?

La Structured Concurrency (JEP 453) complementa a los Virtual Threads garantizando que las tareas concurrentes compartan el mismo ciclo de vida. Este enfoque simplifica la gestión de errores y la cancelación.

```java
// StructuredConcurrencyExample.java
// Combining Virtual Threads + Structured Concurrency
public class StructuredConcurrencyExample {

    public UserDashboard fetchDashboard(Long userId) throws Exception {
        // StructuredTaskScope ensures all tasks complete together
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {

            // Three parallel tasks on Virtual Threads
            Subtask<UserProfile> profileTask = scope.fork(() ->
                userService.getProfile(userId));

            Subtask<List<Notification>> notifTask = scope.fork(() ->
                notificationService.getRecent(userId));

            Subtask<AccountBalance> balanceTask = scope.fork(() ->
                accountService.getBalance(userId));

            // Wait for all tasks or fail on first error
            scope.join();
            scope.throwIfFailed();

            // All tasks succeeded - safe aggregation
            return new UserDashboard(
                profileTask.get(),
                notifTask.get(),
                balanceTask.get()
            );
        }
        // If one task fails, others are automatically cancelled
    }
}
```

La Structured Concurrency previene las fugas de hilos y simplifica la depuración, ya que el call stack refleja la estructura lógica del código.

### Pregunta 14: ¿Cuál es la diferencia entre Virtual Threads y programación reactiva?

Ambos enfoques resuelven el mismo problema (eficiencia de E/S) pero con modelos de programación distintos. Los Virtual Threads permiten un código imperativo clásico, mientras que la programación reactiva exige reescribirlo en forma de streams.

```java
// ComparisonService.java
// Same logic: imperative vs reactive
@Service
public class ComparisonService {

    // VIRTUAL THREADS APPROACH: classic imperative code
    // Easy to read, debug, and maintain
    public UserData getUserDataImperative(Long id) {
        User user = userRepository.findById(id).orElseThrow();
        List<Order> orders = orderRepository.findByUserId(id);
        PaymentInfo payment = paymentService.getInfo(id);

        return new UserData(user, orders, payment);
    }

    // REACTIVE APPROACH: streams and operators
    // More complex but native backpressure
    public Mono<UserData> getUserDataReactive(Long id) {
        return userRepository.findById(id)
            .zipWith(orderRepository.findByUserId(id).collectList())
            .zipWith(paymentService.getInfo(id))
            .map(tuple -> new UserData(
                tuple.getT1().getT1(),
                tuple.getT1().getT2(),
                tuple.getT2()
            ));
    }
}
```

| Criterio | Virtual Threads | Reactivo |
|----------|-----------------|----------|
| Curva de aprendizaje | Baja | Alta |
| Depuración | Stack traces clásicos | Compleja |
| Backpressure | Manual | Nativo |
| Ecosistema | Creciente | Maduro |
| Migración legacy | Sencilla | Reescritura |

Los Virtual Threads se recomiendan para nuevas aplicaciones y migraciones. La programación reactiva conserva su pertinencia en casos que requieren un backpressure sofisticado.

### Pregunta 15: ¿Cómo gestionar ThreadLocal con Virtual Threads?

ThreadLocal funciona con los Virtual Threads pero consume memoria por cada instancia. Los Scoped Values (JEP 446) ofrecen una alternativa más eficiente para el reparto de contexto.

```java
// ThreadLocalVsScopedValue.java
// Comparing context approaches
public class ThreadLocalVsScopedValue {

    // CLASSIC APPROACH: ThreadLocal
    // Works but expensive with millions of VT
    private static final ThreadLocal<RequestContext> requestContext =
        new ThreadLocal<>();

    public void processWithThreadLocal(Request request) {
        requestContext.set(new RequestContext(request.getTraceId()));
        try {
            // Context accessible everywhere in the thread
            processRequest();
        } finally {
            requestContext.remove(); // Important to prevent leaks
        }
    }

    // MODERN APPROACH: ScopedValue (Java 21+)
    // More efficient, immutable, explicit scope
    private static final ScopedValue<RequestContext> CONTEXT =
        ScopedValue.newInstance();

    public void processWithScopedValue(Request request) {
        ScopedValue.where(CONTEXT, new RequestContext(request.getTraceId()))
            .run(() -> {
                // Context accessible within this scope
                processRequest();
                // No cleanup needed - automatic at scope end
            });
    }

    private void processRequest() {
        // Context access
        String traceId = CONTEXT.isBound()
            ? CONTEXT.get().getTraceId()
            : "unknown";
        log.info("Processing with trace: {}", traceId);
    }
}
```

Los ScopedValues se recomiendan para los nuevos desarrollos. Para el código heredado que utiliza ThreadLocal, se aconseja una migración progresiva.

## Conclusión

Los Virtual Threads transforman el desarrollo backend en Java al permitir un código sencillo y de alto rendimiento. Puntos clave:

**Fundamentos:**
- Activación con `spring.threads.virtual.enabled=true`
- Idóneos para cargas I/O-bound (REST, BD, archivos)
- Evitar para cálculos intensivos en CPU

**Rendimiento:**
- Dimensionar correctamente los pools de conexiones (nuevo cuello de botella)
- Vigilar el pinning con `-Djdk.tracePinnedThreads`
- Migrar `synchronized` a `ReentrantLock`

**Migración:**
- Probar progresivamente por grupos de endpoints
- Validar la compatibilidad de las dependencias
- Recurrir a la Structured Concurrency para operaciones paralelas

Dominar los Virtual Threads distingue a los candidatos que comprenden los retos de rendimiento de las aplicaciones modernas. Estos conceptos resultan ya imprescindibles en las entrevistas técnicas de Spring Boot.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/es/blog/spring-boot/spring-boot-virtual-threads-interview