Develop Reference

generic thread framework vs asynctask

I have a few questions about the the usages of a generic thread framework(for a specific amount of jobs of course) vs the usage of many asyntasks.
I would like to know if it is better to have many asyntasks for small jobs, a handler thread when the job takes a bit longer or it is better to have a generic thread by yourself having generic jobs with a notification system built on top of the the running thread(or a subclass, same story).
My idea is for creating thread that handles different jobs without knowing beforehand which are the jobs. This goes in the direction of creating a sort of small framework for handling different generic jobs.
For example my approach goes in the direction of the code below:
public (abstract if you want to extend and add something on top) class WorkerThread extends Thread {
private static final String TAG = WorkerThread();
private List<WorkTask> syncQueue = new ArrayList< WorkTask >();
private boolean clearQueue = false;
public WorkerThread() {
}
public void stop(boolean clear) {
clearQueue = clear;
this.stopWorker = true;
}
public void addTask(WorkerTask task) {
synchronized (syncQueue) {
if (task != null && !getSynQueue().contains(task)) {
getSynQueue().add(task);
}
}
}
#Override
public void run() {
while (!stopWorker) {
WorkerTask task = null;
synchronized (syncQueue) {
if (!getSynQueue().isEmpty()) {
task = getSynQueue().get(0);
}
}
if (task != null) {
try {
task.run();
synchronized (syncQueue) {
if (!getSynQueue().isEmpty()) {
getSynQueue().remove(task);
//notify something/someone
}
}
} catch (Exception e) {
Log.e(TAG, "Error in running the task." + e.getMessage());
synchronized (syncQueue) {
//again u can notify someone
}
} finally {
//here you can actually notify someone of success
}
}
}
if(clearQueue){
getSynQueue().clear();
}
}
private List<WorkerTask> getSynQueue() {
return this.syncQueue;
}
}
Here the task is the abstract base class that all the jobs extend.
Then on top of this thread or a subclass of this class can be an observer that notifies when something went wrong with the jobs/tasks.
So far, as I know, the pros and cons for my approach are like that:
Thread:
Pros:
1. Long time operations.
2. Centralized.
3. Scalable.
4. Once you have it properly tested it will work smoothly.
Cons
1. Complex architecture.
2. Hard to maintain.
3. Over-engineering for small jobs.
AsynTask:
Pros
1. Easy to be used.
2. Good for short-time operation jobs.
3. Easy to maintain/understand.
Cons
1. Cannot scale that much, you need to stick to doInBackground and onPostExecute.
2. Not good for long-time operation jobs.
If I missed something please correct me.
Final question would be, when the architecture gets a bit big with a lot of requests, short-time, long-time, isn't it better to try and make a generic framework that can handle it both rather than do it with asynctasks there, maybe handlerthread in other parts, etc?

AsyncTask should be used for short operations. From the official documentation:
AsyncTask
AsyncTask is designed to be a helper class around Thread and Handler
and does not constitute a generic threading framework. AsyncTasks
should ideally be used for short operations (a few seconds at the
most.) If you need to keep threads running for long periods of time,
it is highly recommended you use the various APIs provided by the
java.util.concurrent package such as Executor, ThreadPoolExecutor and
FutureTask.
Therefore, if the operation is designed to take longer than a few seconds, it is recommended to use the concurrent package. E.g of operations are, storing a file, a picture, a login, etc.
However, Asynctask has also a few limitations as it can be seen in the link below:
AsyncTask limitations
There is a limit of how many tasks can be run simultaneously. Since AsyncTask uses a thread pool executor with max number of worker threads (128) and the delayed tasks queue has fixed size 10. If you try to execute more than 138 AsyncTasks the app will crash with java.util.concurrent.RejectedExecutionException.
Also, between Api 1.6 and 3.0 there is no way to customize the AsyncTask. It can run tasks in parallel but no customization possible. A
Between API 3.0 and API 4.3.1 there is a default fixed delayed queue size of 10, a minimum number of tasks, 5, and a maximum number of tasks 128. However, after API 3.0, one can define its own executor.
Therefore, if you have a number of minimum 16 tasks to run, the first 5 will start, the next 10 will go into the queue, but from the 16th a new worker thread will be allocated. After version 4.4(kitkat), the number of parallel asynctasks depends on the amount of processors that a device has:
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
private static final int CORE_POOL_SIZE = CPU_COUNT + 1;
private static final int MAXIMUM_POOL_SIZE = CPU_COUNT * 2 + 1;
private static final BlockingQueue<Runnable> sPoolWorkQueue = new LinkedBlockingQueue<Runnable>(128);
The aforementioned details, make the AsyncTask usable only in very specific cases, like loading an image or a file from or to the storage.
On the hand a generic threading framework(or library) can be easily extendable and customizable. Example of libraries is the RxJava that is easily customizable. Using RxJava one can specify task to run on either UI thread and background. Also, for loading/saving pictures asynchronously to/on the sdcard, one can use different libraries like Picasso or Glide.

Making AsyncTasks to run automatically

I have a list containing URLs of Images that I want to download with Android's DownloadManager. It's a pretty basic design to define a AsyncTask subclass that removes an object from the list and then invokes the DownloadManager. My problem is how to handle the parallelism of the AsyncTasks when each of those will list.get(curentIndex). To make things clear I want each Task (which will be running on the Executor so running in parallel amongst the others not only the Main Thread) to run atomically the action that
will remove the objects from the lists
will and increment the index

This is in general a synchronization problem. There are many ways to tackle this. I would suggest something along the lines:
// Your index. Defaulted at 0. Thread safe Integer wrapper object.
// All set/get operations are guaranteed atomical.
AtomicInteger mIndex = new AtomicInteger(0);
// Your list. This is thread-safe. All mutative operations
// are atomical, and properly locked. The list is copied on each write.
// This solution, though it does what it needs to do, is SLOW. Don't use for
// large lists.
CopyOnWriteArrayList<Object> mList = ... ;
// Your async task. Maybe more of them.
AsyncTask mTask = ...;
// Anything here that should be thread safe.
ensurePrerequisites(mTask);
// Execute on thread pool to make sure they're parallel.
// CAUTION: You will still get only (CPU_CORE_COUNT + 1) max parallel tasks.
mTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR);
public void synchronized ensurePrerequisites(AsyncTask task) {
// I assume you want to pass the values into the task.
int idx = mIndex.getAndIncrement();
task.setIndex(idx);
task.setObject(mList.remove(idx));
}

AsyncTask memory leak

does creating asyncTask like
AsyncTask<Void,Void,Void> newTask = new AsyncTask<Void,Void,Void>{
....
}
newTask.execute()
create memory leaks?

ok then #sherays Especially in Your case, If you execute another request to the server while previous one is not finished yet (in case of similar requests), this is a chance of memory leak.
Actually, there shouldn't be any issue with AsyncTask recycling unless You hold any reference to it from param or generate memory leaks inside doInBackground().
So, You might think, that if You're creating many long-running AsyncTasks then it would lead to some memory issues. Actually it's not true (at least on latest Android versions). AsyncTask source code shows that
It uses singleton bounded executor:
private static final int CORE_POOL_SIZE = 5;
private static final int MAXIMUM_POOL_SIZE = 128;
private static final int KEEP_ALIVE = 1;
public static final Executor THREAD_POOL_EXECUTOR
= new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);
That means that executor won't run more than 128 AsyncTasks the same time (128 is not very big per my understanding).
It uses bounded query for the Executor:
private static final BlockingQueue<Runnable> sPoolWorkQueue =
new LinkedBlockingQueue<Runnable>(10);
So, based on the above points, number of created and running the same time AsyncTasks are limited and not so big. So, if Your code inside AsyncTask doesn't create any memory leaks, then per my understanding there's no issue. Same time Android won't let You spam itself with AsyncTasks. Checkout ThreadPoolExecutors description to get familiar with the way it manages a memory (If You worry about too many created threads the same time).
so still,if you face memory leak then cancel the task:
Regarding cancel() call, based on Android documentation for AsyncTask:
Cancelling a task
A task can be cancelled at any time by invoking cancel(boolean). Invoking this method will cause subsequent calls to isCancelled() to return true. After invoking this method, onCancelled(Object), instead of onPostExecute(Object) will be invoked after doInBackground(Object[]) returns. To ensure that a task is cancelled as quickly as possible, you should always check the return value of isCancelled() periodically from doInBackground(Object[]), if possible (inside a loop for instance.)

Yes: is your thread garbage collected after onPostExecute is called or is it still in the memory?
An Async Task will not be canceled or destroyed at the moment the activity is dismissed. If your thread is more or less lightweight and finishes after a small time, just keep it running and add a yourActivity.this.isFinishing() clause in the onPostExecuteMethod.

Remove and terminate all tasks from AsyncTask.THREAD_POOL_EXECUTOR

I want to run a number of AsyncTask's on AsyncTask.THREAD_POOL_EXECUTOR.
I am using the following code.
Tasks[i].executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR,
taskParams);
After certain number of threads was sent to the executor, it no longer accepts new AsyncTasks. (I do not see any errors, but doInBackGroundMethod is not started for some reason).
I suspect this happens because it's pool is full.
Is there any way to reset the executor?
I want to completely terminate all the tasks so that it will start to accept new tasks again and process them immediately.
I tried to terminate the Tasks using their cancel method, but it didn't help.

Are your tasks finishing? Are you handling the apropriate exceptions? How many tasks are you creating?
Keep in mind that AsyncTask.THREAD_POOL_EXECUTOR (at least in API 17; this doc page has a bunch of useful details), is set up with
public static final Executor THREAD_POOL_EXECUTOR = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE, TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);
Where CORE_POOL_SIZE is 5 and MAXIMUM_POOL_SIZE is 128.
The sPoolWorkQueue with
private static final BlockingQueue<Runnable> sPoolWorkQueue = new LinkedBlockingQueue<Runnable>(10);
This means that the queue has a maximum capacity of 10 items.
The THREAD_POOL_EXECUTOR keeps at least 5 threads alive. As tasks are added, they are added to the queue. When the queue fills, then new threads will be spawned, up to 128 (there are other limitations tho).
When this happens (128 threads, the max, are running and the queue is full) then any new tasks will be rejected, and handled with the default handler (since it's not being set explicitly, is AbortPolicy), which throws a RejectedExecutionException.
Make sure that you're not just catching and not handling such exceptions.
One way to deal with this is to create your own ExecutorService (even if it's just your instance of ThreadPoolExecutor with different parameters) and configure the parameters that fit your situation best. Parameters like the queue (you can control the amount of items it can hold, or if it's unbounded, etc) or how to handle rejected tasks.

I can see two reasons to having cancelled AsyncTasks still running:
Either you don't call cancel with mayInterruptIfRunning set to true
Either you do call AsyncTask.cancel(true) but the InterruptedException is miss-handled by the executed code: Make sure your code (and the possible subsequent calls to libraries) don't obfuscate/silence InterruptedExceptions by a try/catch on InterruptedExceptions or even on Exception.

How AsyncTask works in Android

I want to know how AsyncTask works internally.
I know it uses the Java Executor to perform the operations but still some of the questions I am not understanding. Like:
How many AsyncTask can be started at a time in an Android app?
When I start 10 AsyncTask, will all tasks will run simultaneously or one by one?
I have tried with 75000 AsyncTask to test the same. I don't get any problem and seems like all the tasks will be pushed to stack and will run one by one.
Also when I start 100000 AsyncTasks, I start getting OutOfMemoryError.
So is there any limit of no of AsyncTask which can be run at a time?
Note: I have tested these on SDK 4.0

AsyncTask has a rather long story.
When it first appeared in Cupcake (1.5) it handled background operations with a single additional thread (one by one). In Donut (1.6) it was changed, so that a pool of thread had begun to be used. And operations could be processed simultaneously until the pool had been exhausted. In such case operations were enqueued.
Since Honeycomb default behavior is switched back to use of a single worker thread (one by one processing). But the new method (executeOnExecutor) is introduced to give you a possibility to run simultaneous tasks if you wish (there two different standard executors: SERIAL_EXECUTOR and THREAD_POOL_EXECUTOR).
The way how tasks are enqueued also depends on what executor you use. In case of a parallel one you are restricted with a limit of 10 (new LinkedBlockingQueue<Runnable>(10)). In case of a serial one you are not limited (new ArrayDeque<Runnable>()).
So the way your tasks are processed depends on how you run them and what SDK version you run them on.
As for thread limits, we are not guaranteed with any, yet looking at the ICS source code we can say that number of threads in the pool can vary in range 5..128.
When you start 100000 with default execute method serial executor is used.
Since tasks that cannot be processed immediately are enqueued you get OutOfMemoryError (thousands of tasks are added to the array backed queue).
Exact number of tasks you can start at once depends on the memory class of the device you are running on and, again, on executor you use.

let us dive deep into the Android’s Asynctask.java file to understand it from a designer’s perspective and how it has nicely implemented Half Sync-Half Async design pattern in it.
In the beginning of the class few lines of codes are as follows:
private static final ThreadFactory sThreadFactory = new ThreadFactory() {
private final AtomicInteger mCount = new AtomicInteger(1);
public Thread newThread(Runnable r) {
return new Thread(r, "AsyncTask #" + mCount.getAndIncrement());
}
};
private static final BlockingQueue<Runnable> sPoolWorkQueue =
new LinkedBlockingQueue<Runnable>(10);
/**
* An {#link Executor} that can be used to execute tasks in parallel.
*/
public static final Executor THREAD_POOL_EXECUTOR
= new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);
The first is a ThreadFactory which is responsible for creating worker threads. The member variable of this class is the number of threads created so far. The moment it creates a worker thread, this number gets increased by 1.
The next is the BlockingQueue. As you know from the Java blockingqueue documentation, it actually provides a thread safe synchronized queue implementing FIFO logic.
The next is a thread pool executor which is responsible for creating a pool of worker threads which can be taken as and when needed to execute different tasks.
If we look at the first few lines we will know that Android has limited the maximum number of threads to be 128 (as evident from private static final int MAXIMUM_POOL_SIZE = 128).
Now the next important class is SerialExecutor which has been defined as follows:
private static class SerialExecutor implements Executor {
final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();
Runnable mActive;
public synchronized void execute(final Runnable r) {
mTasks.offer(new Runnable() {
public void run() {
try {
r.run();
} finally {
scheduleNext();
}
}
});
if (mActive == null) {
scheduleNext();
}
}
protected synchronized void scheduleNext() {
if ((mActive = mTasks.poll()) != null) {
THREAD_POOL_EXECUTOR.execute(mActive);
}
}
}
The next important two functions in the Asynctask is
public final AsyncTask<Params, Progress, Result> execute(Params... params) {
return executeOnExecutor(sDefaultExecutor, params);
}
and
public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,
Params... params) {
if (mStatus != Status.PENDING) {
switch (mStatus) {
case RUNNING:
throw new IllegalStateException("Cannot execute task:"
+ " the task is already running.");
case FINISHED:
throw new IllegalStateException("Cannot execute task:"
+ " the task has already been executed "
+ "(a task can be executed only once)");
}
}
mStatus = Status.RUNNING;
onPreExecute();
mWorker.mParams = params;
exec.execute(mFuture);
return this;
}
AS it becomes clear from the above code we can call the executeOnExecutor from exec function of Asynctask and in that case it takes a default executor. If we dig into the sourcecode of Asynctask, we will find that this default executor is nothing but a serial executor, the code of which has been given above.
Now lets delve into the SerialExecutor class. In this class we have final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();.
This actually works as a serializer of the different requests at different threads. This is an example of Half Sync Half Async pattern.
Now lets examine how the serial executor does this. Please have a look at the portion of the code of the SerialExecutor which is written as
if (mActive == null) {
scheduleNext();
}
So when the execute is first called on the Asynctask, this code is executed on the main thread (as mActive will be initialized to NULL) and hence it will take us to the scheduleNext() function.
The ScheduleNext() function has been written as follows:
protected synchronized void scheduleNext() {
if ((mActive = mTasks.poll()) != null) {
THREAD_POOL_EXECUTOR.execute(mActive);
}
}
So in the schedulenext() function we initialize the mActive with the Runnable object which we have already inserted at the end of the dequeue. This Runnable object (which is nothing but the mActive) then is executed on a thread taken from the threadpool. In that thread, then "finally "block gets executed.
Now there are two scenarios.
another Asynctask instance has been created and we call the execute method on it when the first task is being executed.
execute method is called for the second time on a same instance of the Asynctask when the first task is getting executed.
Scenario I : if we look at the execute function of the Serial Executor, we will find that we actually create a new runnable thread (Say thread t) for processing the background task.
Look at the following code snippet-
public synchronized void execute(final Runnable r) {
mTasks.offer(new Runnable() {
public void run() {
try {
r.run();
} finally {
scheduleNext();
}
}
});
As it becomes clear from the line mTasks.offer(new Runnable), every call to the execute function creates a new worker thread. Now probably you are able to find out the similarity between the Half Sync - Half Async pattern and the functioning of SerialExecutor. Let me, however, clarify the doubts. Just like the Half Sync - Half Async pattern's Asynchronous layer, the
mTasks.offer(new Runnable() {
....
}
part of the code creates a new thread the moment execute function is called and push it to the queue (the mTasks). It is done absolutely asynchronously, as the moment it inserts the task in the queue, the function returns. And then background thread executes the task in a synchronous manner. So its similar to the Half Sync - Half Async pattern. Right?
Then inside that thread t, we run the run function of the mActive. But as it is in the try block, the finally will be executed only after the background task is finished in that thread. (Remember both try and finally are happening inside the context of t). Inside finally block, when we call the scheduleNext function, the mActive becomes NULL because we have already emptied the queue. However, if another instance of the same Asynctask is created and we call execute on them, the execute function of these Asynctask won’t be executed because of the synchronization keyword before execute and also because the SERIAL_EXECUTOR is a static instance (hence all the objects of the same class will share the same instance… its an example of class level locking) i mean no instance of the same Async class can preempt the background task that is running in thread t. and even if the thread is interrupted by some events, the finally block which again calls the scheduleNext() function will take care of it.what it all means that there will be only one active thread running the task. this thread may not be the same for different tasks, but only one thread at a time will execute the task. hence the later tasks will be executed one after another only when the first task complets. thats why it is called SerialExecutor.
Scenario II: In this case we will get an exception error. To understand why the execute function cannot be called more than once on the same Asynctask object, please have a look at the below code snippet taken from executorOnExecute function of Asynctask.java especially in the below mentioned portion:
if (mStatus != Status.PENDING) {
switch (mStatus) {
case RUNNING:
throw new IllegalStateException("Cannot execute task:"
+ " the task is already running.");
case FINISHED:
throw new IllegalStateException("Cannot execute task:"
+ " the task has already been executed "
+ "(a task can be executed only once)");
}
}
AS from the above code snippet it becomes clear that if we call execute function twice when a task is in the running status it throws an IllegalStateException saying “Cannot execute task: the task is already running.”.
if we want multiple tasks to be executed parallely, we need to call the execOnExecutor passing Asynctask.THREAD_POOL_EXECUTOR (or maybe an user defined THREAD_POOL as the exec parameter.
You can read my discussion on Asynctask internals here.

AsyncTasks has a fixed size queue internally for storing delayed tasks. The queue size by default is 10. For example if you start 15 your tasks in a row, then first 5 will enter their doInBackground(), but the rest will wait in the queue for free worker thread. As one of the first 5 finishes, and thus releases the worker thread, a task from the queue will start execution. In this case at most 5 tasks will run together.
Yes, there is limit of how many tasks can be run run at a time. So AsyncTask uses thread pool executor with limited max number of the worker threads and the delayed tasks queue use fixed size 10. Max number of worker threads is 128. If you try to execute more than 138 custom tasks your application will throw the RejectedExecutionException.

How many AsyncTask can be started at a time in an Android app?
AsyncTask is backed by a LinkedBlockingQueue with a capacity of 10 (in ICS and gingerbread). So it really depends on how many tasks you are trying to start & how long they take to finish - but it's definitely possible to exhaust the queue's capacity.
When I start 10 AsyncTask, will all tasks will run simultaneously or one by one?
Again, this depends on the platform. The maximum pool size is 128 in both gingerbread and ICS - but the *default behavior* changed between 2.3 and 4.0 - from parallel by default to serial. If you want to execute in parallel on ICS you need to call [executeOnExecutor][1] in conjunction with THREAD_POOL_EXECUTOR
Try switching to the parallel executor and spam it with 75 000 tasks - the serial impl. has an internal ArrayDeque that has no upper capacity bound (except OutOfMemoryExceptions ofc).