问题
Currently we are using threads in our application(Java). But there will be some 1000 (or more) threads created at a time.This threads should process the data and store it in db.
This is consuming more memory and I/O.
What could be the best alternative for this?. Scalability,Consistency and performance are the main requirements.
回答1:
Have you tried thread pools? A thread pool consists of a reasonable number of threads (enough to use all processors, but not much more) and re-uses threads (again reducing overhead) to execute a large number of tasks concurrently.
Here is a small example to give you an idea
ExecutorService executor = Executors.newFixedThreadPool(5);
Runnable job = new Runnable() {
public void run() {
// do some work
}
}
executor.execute(job);
If you look at the ScheduledThreadPoolExecutor, you will find a lot of features for executing and scheduling jobs.
回答2:
Try to take a look at the Actor model.
The actor model is a concurrent programming model, in which the workload is distributed between entities running in parallel, called actors.
It is a model in which there is no shared state, actors are isolated and information can flow in the form of messages.
The players receive these messages and can only react manipulating the data in the message (computing or processing on data), sending a message to other players or by creating new actors.
This model is a high level abstraction over mutex-locks and threads, which removes the complexity for the developer and it was designed mainly to build highly available and competing telecom systems, by Ericsson in 1973 on Erlang.
Actors are very lightweight concurrent entities. They process messages asynchronously using an event-driven receive loop. Pattern matching against messages is a convenient way to express an actor's behavior. They raise the abstraction level and make it much easier to write, test, understand and maintain concurrent and/or distributed systems. You can focus on workflow—how the messages flow in the system—instead of low level primitives like threads, locks and socket IO.
In Java/Scala, you can find the Akka framework that is build based on this actor model.
回答3:
Use a thread pool. That way you can define a number of threads that you want to have running. Each new task is put into a queue and waits there until a thread is done with its old task and thus free to process a new task.
This is scaleable, because you can define how many threads you want to have running. You can choose few threads on a device with few processing cores to conserve memory and reduce synchronization overhead, or many threads on a device with many cores. So e.g. if you run this on a device with 4 cores and hyperthreading, choose 8 threads, if you run it on a device with 48 hardware threads then choose 48 threads.
The performance is generally better than starting a new thread for each task, since starting and killing threads does have quite some overhead. Threadpools reuse Threads and thus don't have that overhead.
It is also consistent, since there is a threadpool implementation in the Java standard library.
回答4:
I think you don't need an alternative to multi-threading, just a more efficient thread implementation.
Quasar adds fibers (i.e. lightweight threads) to the JVM, of which you can create even millions rather than few hundreds, so you can get the same performance of async frameworks without giving up the thread abstraction and regular imperative control flow constructs (sequence, loops etc.) available in the language.
It also unifies JVM/JDK's threads and its fibers under a common strand interface, so they can interoperate seamlessly, and provides a porting of java.util.concurrent to this unified concept. This also means your porting effort will be minimal (if any).
On top of strands (either fibers or regular threads) Quasar also offers fully-fledged Erlang-style actors (see here for a comparison with Akka), blocking Go-like channels and dataflow programming, so you can choose the concurrent programming paradigm that suits best your skills and needs without being forced into one.
It also provides bindings for popular and standard technologies (as part of the Comsat project), so you can preserve your code assets because the porting effort will be minimal (if any). For the same reason you can also opt-out easily, should you choose to.
Currently Quasar has bindings for Java 7 and 8, Clojure under the Pulsar project and JetBrains' Kotlin. Being based on JVM bytecode instrumentation, Quasar can really work with any JVM language if an integration module is present, and it offers tools to build additional ones.
Starting with Java9, instrumentation will be automatic and no integration modules will be needed anymore.
来源：https://stackoverflow.com/questions/31263726/what-could-be-the-best-alternative-to-multi-threading