Is java – volatile reference a safe way to pass motionevents between threads?

I'm curious about the security of this method. I've considered passing touch events in my Android application (and testing my understanding of concurrency in Java). This is the basic knowledge:

I have a surfaceview connected to surfaceholder.callback to get user input events, mainly ontouchevent callback. After calling ontouchevent method, I'll see if there is event. Getaction() = = motionevent. Action_ Up, if any, calls the method I named posttouchevent, which is a member method of my application thread, which updates the status of the application and draws it to the canvas

SurfaceView

@Override
public boolean onTouchEvent(final MotionEvent event)
{
    mAppThread.postTouchEvent(event);
}

AppThread

private volatile MotionEvent mInputEvent;

public void postTouchEvent(final MotionEvent event)
{
    this.mInputEvent = event;
}

@Override
public void run()
{
    // while loop ...

    if (this.mInputEvent != null)
    {
        final MotionEvent inputEvent = this.mInputEvent;
        this.mInputEvent == null;

        // update state based on inputEvent (not this.mInputEvent)
    }

    // draw to canvas
}

Now I understand that it is definitely not atomic, but will it not work because I accept it from the framework as immutable? (instead of synchronizing the post method and if statement, I have no problem, but I want to learn.)

That's my idea. I know I'll have a valid reference to the object, but I'm not sure I'll actually see the state of the object. Although everything runs well in the test, I know how rare thread exceptions can be, even if something is broken

In addition, I can see a problem: if another motionevent occurs, the inputevent in the run () method may be set to check this. Minputevent= Null refers to different events, but this is really not a problem

So, what am I missing, or should this be OK for my purpose?

resolvent:

No, it's not safe, but not for what you might expect

ViewRoot.java, line 1841., which is the code for scheduling MotionEvent in the view hierarchy. The 1841 row is part of the finally block. It calls recycle () on the MotionEvent that has just been scheduled.

Motionevents are not garbage collected like most objects. They are merged and recycled to avoid unnecessary memory allocation and garbage collection during event sending. Recycling motionevent will return it to the object pool so that it can be used again later when a new motionevent is needed. After calling recycle(), motionevent should be regarded as invalid

Your sample code may eventually read motionevent objects that have been reused by the framework and now contain completely different data

If you plan to suspend to motionevent after ontouchevent returns, please clone it with motionevent. Obtain (event). The static gets () method will return a new motionevent from the object pool with the same content

When you complete a motionevent you get to return it to the pool, you should call recycle (). If you forget this step, it will not be a big problem. It will become regular Java garbage, and the framework will create new motionevents when needed. However, the system can schedule motionevents very quickly, This enables collaboration with this optimization to produce extraordinary performance differences on some devices