Question

package remotedebug;


public abstract class AppSM extends JDynamicEventProcessor implements SyncCallbackListener
{
    public static final String IN_PROGRESS = "IN_PROGRESS";

    protected EventManager eventMgr;
    protected Synchronizer syncRef = null;
    protected static AppSM _self = null;
    protected AppSMHandler _appHandler = null;
    protected SMServiceHandler _serviceHandlerRef = null;
    protected AppSP _scriptProcessor = null;

    /**
    *  \brief This variable is used for the Trace Logger.
    */
    private static com.tracelibrary.TraceLogger _trace;



    private InfoHolder _stateInfoHolder;

    private ResultInfo _resultInfo;

    public static AppSM getInstance()
    {
        try
        {
            if( _self == null)
            {


                _trace = new com.tracelibrary.TraceLogger();
                _trace.TRACE_LOGGER("AppSM");
                _trace.LOG_TRACE("Creating instance");
                 synchronized(AppSM.class){ 
                if( _self == null){
                _self = new AppGen("App" ,"stb");
                _self.Processor(System.getProperty("DIR"));
                 }
                 }
                return _self;
            }
            else
            {
                _trace.LOG_TRACE("returning instance");
                return _self;
            }
        }
        catch(Exception e)
        {
            e.printStackTrace();
        }
        return null;

    }

我正在运行覆盖服务器进行静态代码分析，但我是根据覆盖率获取错误

检查线程共享字段是否逃避锁定获取＆＃34; erro＆＃34; LOCK_EVASION＆＃34;和类别＆＃34;数据竞争破坏了锁定＆＃34;

我不确定为什么会出现这个问题？
我的问题是为什么即使我使用静态变量也会出现此问题。
在这种情况下，使用volatile会帮助我吗？

4.为什么覆盖率正在给出 correlation_field：_trace的修改可以与无人看守的_self一起竞争。即使我的_trace是静态的，如果我将使我的_trace最终我的问题将解决或不??

4.a) what is unguarded check of _self  
4.b)what is correlated_field

5这个封面报告的内容是什么 thread1_modifies_field：Thread1修改静态字段_self。此修改可以在运行时与此关键部分中的其他相关字段分配重新排序

5.a)what is re-ordered   
5.b)what is correlated field

为了更好地理解，请查看封面服务器提供的信息

1. thread1_checks_field: Thread1 uses the value read from static field _self in the condition AppSM._self == null. It sees that the condition is true.

CID 212049 (#1 of 5): Check of thread-shared field evades lock acquisition (LOCK_EVASION)

5. thread2_checks_field_early: Thread2 checks _self, reading it after Thread1 assigns to _self but before some of the correlated field assignments can occur. It sees the condition AppSM._self == null as being false. It continues on before the critical section has completed, and can read data changed by that critical section while it is in an inconsistent state.
    Remove this outer, unlocked check of _self.
                         if( _self == null)
                         {


    6. correlated_field: The modification of _trace can race with the unguarded check of _self.
                               _trace = new com.tracelibrary.TraceLogger();
                              _trace.TRACE_LOGGER("AppSM");
                              _trace.LOG_TRACE("Creating instance");
    2. thread1_acquires_lock: Thread1 acquires lock ViewerAppSM.class.
                                 synchronized(AppSM.class){ 
    3. thread1_double_checks_field: Thread1 double checks the static field _self in the condition com.AppSM._self == null.
                                 if( _self == null){
    4. thread1_modifies_field: Thread1 modifies the static field _self. This modification can be re-ordered with other correlated field assignments within this critical section at runtime. Thus, checking the value of _self is not an adequate test that the critical section has completed unless the guarding lock is held while checking. If _self is assigned a newly constructed value, note that the JVM is allowed to reorder the assignment of the new reference to _self before any field assignments that may occur in the constructor. Control is switched to Thread2.

Java同步和双重检查问题

为了更好地理解，请查看封面服务器提供的信息

0 个答案: