We Keep Coding

How to globally set thread pool for all CompletableFuture

I am trying to mimic what single threaded async programming in Javascript in Java with the use of async / await library by EA (ea-async). This is mainly because I do not have long-lasting CPU bound computations in my program and I want to code single thread lock free code in Java.
ea-async library heavily relies on the CompletableFuture in Java and underneath Java seems to use ForkJoinPool to run the async callbacks. This puts me into multi threaded environment as my CPU is multi-core. It seems for every CompletableFuture task, I can supply async with my custom thread pool executor. I can supply Executors.newSingleThreadExecutor() for this but I need a way to set this globally so that all CompletableFuture will be using this executor within the single JVM process. How do I do this?

ea-async library heavily relies on the CompletableFuture in Java and
underneath Java seems to use ForkJoinPool to run the async callbacks.
That is the default behavior of CompleteableFuture:
All async methods without an explicit Executor argument are performed
using the ForkJoinPool.commonPool() (unless it does not support a
parallelism level of at least two, in which case, a new Thread is
created to run each task). This may be overridden for non-static
methods in subclasses by defining method defaultExecutor().
That's a defined characteristic of the class, so if you're using class CompleteableFuture, not a subclass, and generating instances without specifying an Executor explicitly, then a ForkJoinPool is what you're going to get.
Of course, if you are in control of the CompletableFutures provided to ea-async then you have the option to provide instances of a subclass that defines defaultExecutor() however you like. Alternatively, you can create your CompleteableFuture objects via the static factory methods that allow you to explicitly specify the Executor to use, such as runAsync​(Runnable, Executor).
But that's probably not what you really want to do.
If you use an executor with only one thread, then your tasks can be executed asynchronously with respect to the thread that submits them, yes, but they will be serialized with respect to each other. You do get only one thread working on them, but it will at any time be working on a specific one, sticking with that one only until it finishes, regardless of the order in which the responses actually arrive. If that's satisfactory, then it's unclear why you want async operations at all.
This puts me into multi threaded environment as my CPU is multi-core.
It puts you in multiple threads regardless of how many cores your CPU has. That's what Executors do, even Executors.newSingleThreadExecutor(). That's the sense of "asynchronous" they provide.
If I understand correctly, you are instead looking to use one thread to multiplex I/O to multiple remote web applications. That is what java.nio.channels.Selector is for, but using that generally requires either managing the I/O operations yourself or using interfaces designed to interoperate with selectors. If you are locked in to third-party interfaces that do not afford use of a Selector, then multithreading and multiprocessing are your only viable alternatives.
In comments you wrote:
I'm starting to think maybe BlockingQueue might do the job in
consolidating all API responses into one queue as tasks where a single
thread will work on them.
Again, I don't think that you want everything that comes with that, and if in fact you do, then I don't see why it wouldn't be even better and easier to work synchronously instead of asynchronously.

Refactoring a multi-thread asynchronous application to prevent too many threads

I'm trying to refactoring a multi-thread asynchronous application. I have a class the every time that the application launch particular event(they are generate from external devices) it launch a new thread and it register the event. After that in another class I launch a new thread that process the event and then close the two thread.
I want refactor this because if are raised 100 different events I' ll have 100 different thread(and the application will run in embedded pc like raspberry pi or marsboard).
So I have found two ways to try to solve the problem:
Use thread pool but it has a limit so I' ll lost event thar are raised after the pool thread as reach the limit
Use a queue: I' ll transform the application in a synchronous and single thread but at most I' ll have only one thread running.
There are other ways to solve the problem?

Combine the two solutions.
Use a threadpool and if there are no free threads, then start to queue up requests.
That is the way application servers solve this problem.

Using unlimited number of threads is a terrible idea indeed,
You can use ThreadPoolExecutor and a BlockingQueue instead. ThreadPoolExecutor has a constructor that takes a BlockingQueue.
Since you mentioned refactoring, try to remove mutability from the code that is gonna be used by threads.
Try to make all your types madly immutable, if this is not possible hide mutability. This will give thread safety for free

Android AsyncTask.THREAD_POOL_EXECUTOR vs custom ThreadPool with Runnables

I have some tasks that I need to process concurrently on Android and I would like to use some sort of a thread pool to do so. I couldn't find in the documentation what actually happens "behind the scenes" when executing an AsyncTask with AsyncTask.THREAD_POOL_EXECUTOR.
My question is: What do I lose by using AsyncTasks with AsyncTask.THREAD_POOL_EXECUTOR as opposed to implementing a custom ThreadPool with Runnables? (Let's talk post-honeycomb).
I realize the question is rather general, but I'm fairly new to doing concurrent programming (besides AsyncTask itself). I'm not looking for a tutorial on concurrent programming! I only seek to understand how the Android specific AsyncTask.THREAD_POOL_EXECUTOR is different. I think an explanation would be helpful for others in the future as they weigh the pros and cons of choosing to use AsyncTask vs Thread/Runnable. Thanks in advance!

AsyncTasks provide you with possibility to execute actions on UI thread before and after executing worker task. So, if you dont need communicating with UI then use your own executor - you can always implement this using handler. AsyncTasks are being executed serially since api 11 because parallel execution was considered to difficult to properly implement.
If you need more flexibility, then executors are a way to go, they will allow you to freely specify how many tasks to execute in parallel, how many to put in queue etc.
If you are interested in details, you can always look into sources:
http://androidxref.com/4.4.3_r1.1/xref/development/samples/training/bitmapfun/BitmapFun/src/main/java/com/example/android/bitmapfun/util/AsyncTask.java

Non-UI work might be taken by anything including AsyncTasks, HandlerThreads, IntentServices etc.
The reason it's suggested AsyncTasks for UI-related works (works that affect UI) is that AsyncTask has helper callbacks that lets you to transfer the control to the UI thread.
However, it's not suggested for longer running operations since it's, by default, uses a global executor and this may cause app-global waiting threads to be stalled while executing long-runnings ops. So you can switch to a custom executor and get rid of global affect.
At the end of the day, HandlerThreads are threads again that gives a Looper to keep the thread alive. Executions will still be done in serial so what's the real reason to use them ? I believe it's the power of ability to execute Runnables like Executors but more in light-weight fashion.
IntentServices are again - the way to execute tasks serially but you've more power and isolation since they're entirely different components has seperate lifecycles. They automatically destroyed so you don't have to worry about destroying them to reduce your app process priority ( off the topic but causes some memory performance problems, trashing etc. )

AsyncTask vs Worker thread for getting information from a MySQL DB

I understand that I cannot access a MySQL DB from the main thread (UI thread). So I know now that I have options for doing so. I can use a worker thread ( Thread t = new Thread() ) to access MySQL db and get what I need or I can do AsyncTask to access MySQL db and get what I need.
But my question here is, what would be the right way of going about this or the most efficient approach here? I really want to understand and follow good programming procedures when I come across this.
So retrieving data from a MySQL db: AsyncTask, a worker thread or would there be no difference time, power etc?

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 pacakge such as Executor, ThreadPoolExecutor and FutureTask. (Straight from the doc).
http://developer.android.com/reference/android/os/AsyncTask.html.
An alternative to asynctask for long running operations is robospice.
https://github.com/octo-online/robospice
Update:
Asynctask is deprecated using coroutines or any other threading mechanism. Consider suing work manager for defferable jobs.

Actually the best way would be to use Loaders. More specific a CursorLoader. The advantage of the Loaders compared to AsyncTasks and Threads is that the Cursors will be tied to your Activity or Fragment lifecycle. So you will not end up in trobule if your AsyncTask or Thread finishes after your Activity or Fragment are stopped, and try to notify a component that is no longer present.
You can find some examples for Loaders here How to Use Loaders, and here Life Before Loaders.

AsyncTask is better compared to Thread
AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.
And go through this Handler vs AsyncTask vs Thread

Does the android.os.Handler class eliminate the need to declare certain methods as synchronized?

In putting together a simple "Clock" application I discovered that Android requires you to use android.os.Handler that lives in Thread A in order to update View objects in Thread A with the results of data that come from Thread B.
I'm still relatively new to Java, and this is the first time I've dealt explicitly with Threads before, but I know that ordinarily you'd declare methods and/or operations as synchronized if two different threads want to access the same data. It appears though, that android.os.Handler is an Android-specific way of synchronizing data between threads such that you avoid the classic concurrency errors detailed in the Oracle documentation I just linked to. Is this really true?
If I were to find myself in a situation such that I were required by the Android OS to use android.os.Handler to ferry data from one thread to another, does that mean I don't have to declare the methods used to derive that data as synchronized?

My understanding:
A Handler is just a mechanism for delivering information between two threads. It's not the only mechanism, but it is the mechanism Google chose to use for adding easy to use methods to Activities to do common tasks.
From the doc
When a process is created for your
application, its main thread is
dedicated to running a message queue
that takes care of managing the
top-level application objects
(activities, broadcast receivers, etc)
and any windows they create. You can
create your own threads, and
communicate back with the main
application thread through a Handler.
This is done by calling the same post
or sendMessage methods as before, but
from your new thread. The given
Runnable or Message will then be
scheduled in the Handler's message
queue and processed when appropriate.
The main thread is running a Handler. The handler is responsible for running your activities and managing the application environment. The Handler is just a message loop which dispatches things from a MessageQueue. This is why your thread has to be running a Looper to create a Handler. To synchronize other stuff you want to do with this effort, you have to insert your requests into this message queue so the main application thread does your work. The ui is written so as long as only one thread accesses the objects, it functions.
I guess the point of this was to point out that the Handler is one mechanism for doing synchronization. Surely, the internals of the MessageQueue are written to take synchronization into account, though its a gross simplification to say 'if multiple threads access it it needs to be synchronized.' Although the UI is the most frequent example, using a Handler and Looper is simply a mechanism for designing a multi-threaded application which provides single thread synchronization for the processing of events.
Whether or not you need to synchronize what you send to a Handler depends greatly on what you are sending. If you are talking about synchronizing the calls to post stuff, then no, the handler takes care of that. If you're talking about code inside a Runnable that you post to a Handler, realize that the only guarantee of the Handler is that your runnable will be executed using the thread that created the Handler. You will need to continue to provide synchronization with other resources.

You only ever need synchronized if you have a shared resource, like an ArrayList or something that can be read from two threads at the same time.
The Handler by itself doesn't prevent any concurrency, it just makes it a lot easier to perform things that need to happen in the UI thread even though a worker thread is trying to do them.
To answer your question: If you use a Handler, it typically means that you do certain critical things in the UI thread. As an example, you have an ArrayList that you initialize in onCreate and then maybe update in a click handler or something. Now if you use a Handler to modify that, then ALL access to the ArrayList will occur in the UI thread, so there is no need for synchronized.
However, as soon as you access that ArrayList from within a worker thread, you WILL need to synchronize every single access to it.

Synchronized, wait and notify are low level concurrency constructs on top of which high level concurrency constructs like semaphores, blocking queues, barriers and Looper/Handler are implemented.
Most of what you see in java.util.concurrent (which implements high level concurrency patterns/constructs) is implemented on top of synchronized, wait and notify (if you ignore the lock free algorithms)
Looper/Handler mechanism in basically a lightweight implementation of producer-consumer pattern where you have one consumer but multiple producers. It was created to easily exchange messages between the UI thread and non UI threads. UI thread in android runs as a single threaded loop (i.e single consumer) but can take in updates from multiple non UI threads (i.e multiple producers via handlers).