Multiverse: программное обеспечение с открытым исходным кодом, транзакционная память для Java. Интервью с создателем

Сегодня мы рады пообщаться с создателем Питера Вентьером и ведущим разработчиком очень интересного проекта с открытым исходным кодом Multiverse.

Привет Питер! Спасибо, что  нашли время поговорить с DZone .  W гип не начать с говоря нам немного о том, что Мультивселенная является

Привет, Алекс, Multiverse — это реализация программной транзакционной памяти для платформы Java, над которой я работаю последние 18 месяцев. Он имеет 2 важных миссии:

1) Создать STM, который легко интегрируется с языком Java

2) Создать STM, который можно интегрировать с другими JVM, такими как Scala, Groovy или JRuby.

Программная транзакционная память. Это звучит здорово. Что оно делает?

Программная транзакционная память является чем-то новым для Java, и идея заключается в том, что она сочетает в себе возможности традиционного управления параллелизмом и простоту программирования баз данных. С базой данных вам нужно меньше беспокоиться о проблемах гонки, частичной записи и взаимоблокировках, так что это значительно упрощает написание параллельной системы. И преимущество использования более традиционного управления параллелизмом состоит в том, что вы получаете очень высокую производительность, потому что все может быть сделано в памяти (или даже в кеше), он легко интегрируется в Java и имеет расширенные функции, такие как операции блокировки.

В связи с постоянно растущей потребностью в написании параллельного кода программистам все чаще приходится сталкиваться с контролем параллелизма. Мой опыт показывает, что большинство разработчиков находят эту тему очень сложной, и часто код наполняется всевозможными ошибками. Начиная от проблем гонки и заканчивая более сложными проблемами, такими как видимость и изменение порядка. Идея STM состоит в том, чтобы снова облегчить жизнь основным разработчикам программного обеспечения.

Может быть, вы хотите поделиться с нами некоторым фрагментом кода, чтобы немного лучше понять концепцию?

Это простой пример банковского счета:

public class Account{
  private int balance;

  public Account(int balance){
    setBalance(balance);
  }

  public int getBalance(){ return balance; }

  public void setBalance(int newBalance){
    if(newBalance < 0){
       throw new IllegalStateException("negative balance not allowed");
    }
    balance = newBalance;
  }
}

Если эта учетная запись используется несколькими потоками, могут начаться странные вещи. Если 2 потока хотят перевести деньги со счета, оба прочитайте баланс, удалите сумму и запишите новый баланс. Если на счете 10 евро, и обе потоки хотят перевести 5 евро, результат в итоге составит 0 евро. Но если это делается одновременно, может случиться так, что конечный результат составит 5 евро. Это вызвано проблемой гонки, и это одна из самых сложных частей параллельного программирования: выяснение того, что нужно заблокировать. Стандартным решением было бы посыпать код синхронизированными, например:

public class Account{
   private int balance;

   public Account(int balance){
     setBalance(balance);
   }

   public synchronized int getBalance(){
     return balance;
   }

   public synchronized void setBalance(int newBalance){
     if(newBalance < 0){
       throw new IllegalStateException("negative balance not allowed");
     }
     balance = newBalance;
   }
} 

Но это все еще не решает проблему гонки, потому что все еще может случиться так, что конечный результат  будет  5  вместо 0. Для этого необходимо получить блокировку на Счете, чтобы сделать безопасный перевод:

synchronized(account){

int balance = account.getBalance();

account.setBalance(balance-amount);

}

Проблема этого подхода заключается в том, что объект учетной записи должен предоставлять внутреннюю блокировку. Так что вам нужно раскрыть детали вашей реализации. Это даже усложняется, когда используются 2 счета и деньги переводятся с одного на другой, потому что система может зайти в тупик.

Итак, как STM помогает здесь?  

Пример объясняет более тысячи слов

@TransactionalObject
public class Account{
  private int balance;

  public Account(int balance){
     setBalance(balance);
  }

   public int getBalance(){return balance;}

   public void setBalance(int newBalance){
    if(newBalance < 0){
      throw new IllegalStateException("negative balance not allowed");
    }
    balance = newBalance;
  }
} 

Добавляя аннотацию «TransactionalObject», STM будет следить за тем, чтобы не возникало проблем с гонкой. Все методы экземпляра Аккаунта стали атомарными, и самое интересное в том, что они также могут быть созданы без боязни зайти в тупик, например:

@TransactionalMethod
public static void transfer(Account from, Account to, int amount){
   from.setBalance(from.getBalance()-amount);
   to.setBalance(to.getBalance()+amount);
}

Так что как разработчик вы можете работать в декларативном режиме; вы указываете, что должно быть транзакционным, и STM обеспечит его реализацию. Это похоже на модель программирования базы данных, где вы можете определить уровни изоляции, а база данных убедиться, что они не нарушены.

Что произойдет, если одна из операций не удалась?

Может произойти сбой операции, например, из-за того, что обнаружена взаимоблокировка или возник конфликт. Поведение по умолчанию — операция повторяется. Если используется инструментарий или TransactionalTemplate, повторная попытка выполняется автоматически. Поведение можно контролировать, задав максимальное количество повторов (по умолчанию 1000) и настроив политику отката, которая предотвращает перегрузку в системе.

Поскольку операции могут быть повторены, очень важно понять, что может случиться с нетранзакционными объектами / ресурсами, используемыми внутри транзакций, потому что эти ресурсы не откатываются. Например, выполнение ввода-вывода является хорошим примером того, что может быть проблематичным в транзакции.

Это звучит слишком хорошо. Какую цену мы платим за такие вкусности? Производительность?

Это действительно зависит. Это влияет на производительность, поскольку аппаратная поддержка транзакционной памяти отсутствует. Таким образом , нарушение должно быть проверено в программном обеспечении , так как это вызывает увеличение в  использование процессора. Но есть также увеличение в  использование памяти, потому что нужно отслеживать больше информации. Я не ожидаю, что STM заменит традиционный контроль параллелизма, я вижу их скорее как гибрид между базами данных и традиционным контролем параллелизма.