在Android上，如果按下后退按钮，可运行线程会如何处理？

Question

I have a Runnable (say " MyThread ") that executes a long task and also uses/locks a Thread-Safe Singleton.

I have noticed that when the back button is pressed the screen immediately exits the activity and there is no visual indication that the MyThread has properly finished.

This is evidenced also by the fact that when I 'reopen' my app the singleton is still locked!!!! and of course getLockedInstance() returns null.

So I guess my question is.... what exactly happens to android applications when the back button is pressed even when it is executing critical tasks? Are the threads terminated? Are the threads of the activity frozen and therefore all data being accessed and used? How do we ensure critical tasks are allowed to finish executing?

// singleton class
public class Storage
{
    private int count = 0;
    private static final Storage ourInstance = new Storage();

    public static synchronized Storage getLockedInstance()
    {
        if (ourInstance.count > 0)
            return null;
        ourInstance.count++;
        return ourInstance;
    }

    public synchronized void UnlockInstance()
    {
        if (count > 0)
            count--;
    }
}

// runnable declaration

private Runnable MyThread = new Runnable()
{
    @Override
    public void run()
    {
        Storage s = Storage.getLockedInstance();

        ..... do stuff .....
        [back button pressed]
        ..... this is never reached .....

        s.UnlockInstance();
    }
}

Answer 1

The Thread class in Android is no different from the Thread class in regular Java programming. It is the closest representation of the underlying Linux native thread an application gets. The Thread class creates the execution environment for tasks, represented by Runnable. The Thread implements Runnable, so the task to be executed is either defined by the thread itself or injected during thread creation.

When the run method has finished execution, the thread is terminated and its resources can be freed. This is the final state of the thread; no re-use of the Thread instance or its execution environment is possible.

Interruptions (such as pressing back button)

Occasionally, an application wants to terminate the thread's execution before it has finished its task. For instance, if a thread is taking a long time to download a video and the user presses a button to cancel the download, the UI thread captures the button press and would like to terminate the downloading thread. There is, however, no way a thread can be directly terminated. Instead, threads can be interrupted, which is an request to the thread that is should terminate, but it is the thread itself that determines whether to oblige or not. Interruptions are invoked on the thread reference:

Thread interruption is implemented collaboratively: the thread makes itself available to be interrupted, and other threads issue the call to interrupt it. Issuing an interruption has no direct impact on the execution of the thread; it merely sets an internal flag on the thread that marks it as interrupted. The interrupted thread has to check the flag itself to detect the interruption and terminate gracefully. A thread must implement cancellation points in order to allow other threads to interrupt it and get it to terminate.

Answer 2

(Posted on behalf of the OP) .

Thanks to everyone (and @AJ AJ) for their comments and help. I had misdiagnosed the problem and actually the problem was mine.

The thread does actually finish executing, but since it is a long process, access to the Storage object is blocked to whatever activity the app is resumed to. My solution was to use a getLockedInstanceWait() function (see below) instead of the "lock and return" type previously utilized:

public static Storage getLockedInstanceWait()
{
    Storage s = null;
    while ((s = Storage.getLockedInstance()) == null)
    {
        try
        {
            Thread.sleep(500);
        }
        catch (InterruptedException e)
        {
            return null;
        }
    }

    return s;
}