Инструменты для нахождения Общих Изменяемых ошибок при работе с данными в Java

Анализатор Потока Coverity делает задание, но это довольно дорого. Аналитический Инструмент Времени выполнения Мультипотока IBM для Java, кажется, может обнаружить их, но кажется несколько более трудным настроить. Это динамические аналитические инструменты, которые обнаруживают, к каким фактическим переменным получили доступ от различных потоков без надлежащей синхронизации или энергозависимости, таким образом, результаты более точны, чем со статическим анализом и могут найти много проблем, которые статический анализ не может обнаружить.

, Если Ваш код главным образом или по крайней мере частично правильно синхронизируется, фиксируя FindBugs (или другой статический анализ) проверки параллелизма могли бы помочь также, по крайней мере, управляет IS2_INCONSISTENT_SYNC, и UG_SYNC_SET_UNSYNC_GET мог бы быть хорошими для запуска с.

Chris Grindstaff записал статью FindBugs, Часть 2: Запись пользовательских детекторов, в которых он описывает, как использовать BCEL для добавления собственных правил. (BCEL не является единственной библиотекой байт-кода - но это - то, используемое FindBugs.)

Код ниже испускает любые случаи, где метод получает доступ к статическому методу или полю. Вы могли выполнить его на любом типе, который реализует Выполнимый.

public class StaticInvocationFinder extends EmptyVisitor {

    @Override
    public void visitMethod(Method obj) {
        System.out.println("==========================");
        System.out.println("method:" + obj.getName());

        Code code = obj.getCode();
        InstructionList instructions = new InstructionList(code.getCode());
        for (Instruction instruction : instructions.getInstructions()) {
            // static field or method
            if (Constants.INVOKESTATIC == instruction.getOpcode()) {
                if (instruction instanceof InvokeInstruction) {
                    InvokeInstruction invokeInstruction = (InvokeInstruction) instruction;
                    ConstantPoolGen cpg = new ConstantPoolGen(obj
                            .getConstantPool());
                    System.out.println("static access:"
                            + invokeInstruction.getMethodName(cpg));
                    System.out.println("      on type:"
                            + invokeInstruction.getReferenceType(cpg));
                }
            }
        }
        instructions.dispose();
    }

    public static void main(String[] args) throws Exception {
        JavaClass javaClass = Repository.lookupClass("StopThread$1");

        StaticInvocationFinder visitor = new StaticInvocationFinder();
        DescendingVisitor classWalker = new DescendingVisitor(javaClass,
                visitor);
        classWalker.visit();
    }

}

Этот код испускает следующее:

==========================
method:<init>
==========================
method:run
static access:access$0
      on type:StopThread

Было бы возможно затем просканировать тип StopThread, найти, что поле и проверка видят, энергозависимо ли это.

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

BCEL выглядит скудно зарегистрированным и действительно волосатым, пока Вы не находите класс BCELifier. При выполнении его на классе это выкладывает источник Java того, как Вы создали бы класс в BCEL. Выполнение его на StopThread дает это для генерации синтетического средства доступа за 0 access$:

  private void createMethod_2() {
    InstructionList il = new InstructionList();
    MethodGen method = new MethodGen(ACC_STATIC | ACC_SYNTHETIC, Type.BOOLEAN, Type.NO_ARGS, new String[] {  }, "access$0", "StopThread", il, _cp);

    InstructionHandle ih_0 = il.append(_factory.createFieldAccess("StopThread", "stopRequested", Type.BOOLEAN, Constants.GETSTATIC));
    il.append(_factory.createReturn(Type.INT));
    method.setMaxStack();
    method.setMaxLocals();
    _cg.addMethod(method.getMethod());
    il.dispose();
  }

Последняя версия FindBugs попытается проверить, что к полям, отмеченным с @GuardedBy аннотация, получают доступ только в рамках соответствующего защитного кода.

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

, Если вещи находятся в том плохо форма, то необходимо добавить инструменты с анализом экспертом по параллелизму Java - человеком.

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

Coverity делает некоторые инструменты статического и динамического анализа, которые могут помочь.

http://www.coverity.com/