В чем разница между методами в которых может и не может работать корутина?

# Где и когда могут работать корутины в Java

Корутины в Java (представленные в preview в Java 19-20 через проект Loom) имеют специфические ограничения относительно того, где они могут безопасно работать. Это связано с особенностями механизма виртуальных потоков и точек блокировки.

Основное правило: блокирующие операции

Корутина — это облегчённый поток, который может быть заморожен (suspended) и возобновлён (resumed). Ключевая разница между местами, где корутины могут и не могут работать, заключается в наличии блокирующих операций.

Где МОГУТ работать корутины

1. В обычных Java методах с I/O операциями

Виртуальные потоки (корутины) специально разработаны для работы с блокирующимися операциями. Они могут быть подвешены и возобновлены, позволяя эффективно использовать системные ресурсы.

public class VirtualThreadExample {
  
  // Метод, где ОТЛИЧНО работают корутины
  public String fetchDataFromApi(String url) {
    try {
      // Блокирующий I/O — виртуальный поток заморозится, но не будет
      // занимать системный поток
      HttpClient client = HttpClient.newHttpClient();
      HttpRequest request = HttpRequest.newBuilder()
        .uri(URI.create(url))
        .build();
      HttpResponse<String> response = client.send(request, 
        HttpResponse.BodyHandlers.ofString());
      return response.body();
    } catch (Exception e) {
      return "Error: " + e.getMessage();
    }
  }
  
  // Использование виртуальных потоков
  public void processRequests(List<String> urls) {
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
      for (String url : urls) {
        executor.submit(() -> {
          // Корутина безопасно работает с блокирующимся I/O
          String result = fetchDataFromApi(url);
          System.out.println("Result: " + result);
        });
      }
    }
  }
}

2. Методы с blocking операциями

• I/O операции: Socket, FileInputStream, HttpClient, Database queries
• Синхронизация: Thread.sleep() (в контексте виртуального потока безопасна)
• Lock-based синхронизация: synchronized блоки, ReentrantLock
• Ожидание в очередях: BlockingQueue.take(), Queue.poll() с timeout

public class BlockingOperationsInVirtualThreads {
  
  // Работает отлично в виртуальном потоке
  public void readFromDatabase(String query) throws SQLException {
    try (Connection conn = DriverManager.getConnection("jdbc:postgresql://localhost/db")) {
      PreparedStatement stmt = conn.prepareStatement(query);
      // Эта операция заблокирует виртуальный поток, но не системный
      ResultSet rs = stmt.executeQuery();
      while (rs.next()) {
        System.out.println(rs.getString(1));
      }
    }
  }
  
  // Тоже работает безопасно
  public synchronized void synchronizedMethod() {
    try {
      Thread.sleep(1000);  // Виртуальный поток заморозится
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
    }
  }
}

Где НЕ МОГУТ работать корутины безопасно

1. Методы с "pinning" точками

Pinning — это ситуация, когда виртуальный поток не может быть заморожен и вынуждает занимать системный поток. Это происходит в нескольких случаях:

a) Внутри synchronized блоков (классический монитор)

public class PinningExample {
  
  private Object monitor = new Object();
  
  // ПЛОХО: виртуальный поток "приколется" к системному потоку
  public void unsafeMethodWithSynchronized() {
    synchronized (monitor) {
      // Если здесь произойдёт блокирующая операция (I/O, sleep),
      // виртуальный поток не может быть заморожен без системного потока
      try {
        Thread.sleep(1000);
      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    }
  }
  
  // ХОРОШО: использовать ReentrantLock вместо synchronized
  private final Lock lock = new ReentrantLock();
  
  public void safeMethodWithLock() {
    lock.lock();
    try {
      // Реентрантная блокировка позволяет виртуальному потоку работать корректно
      Thread.sleep(1000);
    } finally {
      lock.unlock();
    }
  }
}

b) В JNI (Java Native Interface) коде

public class JNIExample {
  
  static {
    System.loadLibrary("nativelib");
  }
  
  // ПЛОХО: JNI метод не может быть заморожен
  private native void nativeBlockingOperation();
  
  public void problematicMethod() {
    // Эта операция заставит виртуальный поток "приколеться"
    nativeBlockingOperation();
  }
}

c) В foreign function interface (FFI)

// Проект Panama (Java 19+)
public class FFIExample {
  
  // Функции через FFI обычно не могут быть безопасно заморожены
  // если они выполняют длительные операции
  public void callCFunction() {
    // Может привести к pinning
    // long result = nativeCFunction();
  }
}

2. Computationally intensive операции

Хотя технически корутины МОГУТ работать в вычислительно интенсивных методах, это НЕ рекомендуется, так как они не дают преимущества:

public class ComputeIntensiveExample {
  
  // Виртуальные потоки НЕ помогут здесь
  public int expensiveCalculation(int n) {
    int result = 0;
    for (int i = 0; i < n * 1_000_000; i++) {
      result += Math.sqrt(i);
    }
    return result;
  }
  
  // Для таких операций используй обычные потоки или ForkJoinPool
  public void wrongUseOfVirtualThreads() {
    try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
      executor.submit(() -> {
        // Виртуальный поток будет занят вычислениями
        // и не сможет работать с другими задачами
        expensiveCalculation(1000);
      });
    }
  }
}

Практическая таблица

Практический пример правильного использования

public class ProperVirtualThreadUsage {
  
  public static void main(String[] args) throws InterruptedException {
    ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();
    
    List<String> urls = List.of(
      "https://api.github.com",
      "https://api.github.com/users/torvalds",
      "https://api.github.com/repos/linux/linux"
    );
    
    for (String url : urls) {
      executor.submit(() -> {
        try {
          // Виртуальный поток будет заморожен при блокирующем I/O
          // Системный поток будет обслуживать другие виртуальные потоки
          HttpClient client = HttpClient.newHttpClient();
          HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(url))
            .timeout(java.time.Duration.ofSeconds(10))
            .build();
          HttpResponse<String> response = client.send(request,
            HttpResponse.BodyHandlers.ofString());
          System.out.println("Status " + url + ": " + response.statusCode());
        } catch (Exception e) {
          System.err.println("Error fetching " + url + ": " + e.getMessage());
        }
      });
    }
    
    executor.shutdown();
    executor.awaitTermination(60, java.util.concurrent.TimeUnit.SECONDS);
  }
}

Выводы

1. Корутины (виртуальные потоки) созданы для I/O операций — это их основная сила
2. Избегай synchronized блоков — используй ReentrantLock или java.util.concurrent
3. Не используй JNI и FFI — они вызывают pinning
4. Для вычислений используй обычные потоки — ForkJoinPool или ScheduledExecutorService
5. Pinning — главный враг производительности — инструменты мониторинга помогут выявить проблемы

Основное правило: если метод содержит блокирующие операции (I/O, sleep) вне synchronized блоков — корутина будет работать эффективно. Если метод содержит pinning-точки — лучше использовать обычные потоки.