# V6102. Inconsistent synchronization of a field. Consider synchronizing the field on all usages.

Анализатор обнаружил поле, к которому производится обращение без синхронизации, хотя большая часть обращений к данному полю производилась в синхронизированном контексте.

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

Иначе говоря, поля должны либо синхронизироваться во всех случаях использования, либо не синхронизироваться вообще, чтобы не запутать разработчиков, которые будут поддерживать этот код. Поэтому, если анализатор выдает вам предупреждение V6102, рекомендуется удостовериться, что все обращения к полю полностью синхронизированы.

Простой пример из реального проекта, где доступ к полю 'acked' синхронизирован во всех случаях, кроме одного:

    public class FixedTupleSpout implements IRichSpout
    {
      private static final Map<String, Integer> acked = new HashMap<>();
      ....

      public static int getNumAcked(String stormId)
      {
        synchronized (acked)
        {
          return get(acked, stormId, 0);
        }
      }

      public static void clear(String stormId)
      {
        acked.remove(stormId);                         // <=
        ....
      }

      public int getCompleted()
      {
        synchronized (acked)
        {
          ackedAmt = acked.get(_id);
        }
        ....
      }

      public void cleanup()
      {
        synchronized (acked)
        {
          acked.remove(_id);
        }
        ....
      }
    }

Из-за того, что доступ к 'acked' в методе 'clear' несинхронизирован, есть вероятность одновременного доступа к полю из разных потоков. Так как 'acked' непотокобезопасная коллекция HashMap, то велика вероятность испортить внутреннее состояние объекта. Чтобы исправить это, выражение 'acked.remove(stormId)' нужно заключить в блок 'synchronized':

    public class FixedTupleSpout implements IRichSpout
    {
      private static final Map<String, Integer> acked = new HashMap<>();
      ....

      public static int getNumAcked(String stormId)
      {
        synchronized (acked)
        {
          return get(acked, stormId, 0);
        }
      }

      public static void clear(String stormId)
      {
        synchronized (acked))
        {
          acked.remove(stormId);
        }
        ....
      }

      public int getCompleted()
      {
        synchronized (acked)
        {
          ackedAmt = acked.get(_id);
        }
        ....
      }

      public void cleanup()
      {
        synchronized (acked)
        {
          acked.remove(_id);
        }
        ....
      }
    }

Выявляемые диагностикой ошибки классифицируются согласно ГОСТ Р 71207–2024 как критические и относятся к типу: Ошибки при работе с многопоточными примитивами (интерфейсами запуска потоков на выполнение, синхронизации и обмена данными между потоками и пр.).

Данная диагностика классифицируется как:

CWE-662

Взгляните на примеры ошибок, обнаруженных с помощью диагностики V6102.