executorservice

newFixedThreadPool() vs newCachedThreadPool() [duplicate]

倖福魔咒の 提交于 2019-12-07 14:37:26
问题 This question already has answers here : Executors.newCachedThreadPool() versus Executors.newFixedThreadPool() (8 answers) Closed 4 years ago . In case newCachedThreadPool() as per creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available whereas in case of newFixedThreadPool(int size) specify size to create the thread pool with size specified. Why isn't newFixedThreadPool(int size) implemented in newCachedThreadPool()

How can I report progress from a background task?

£可爱£侵袭症+ 提交于 2019-12-07 08:45:58
问题 I have a long running task that is executing in the background on an ExecutorService thread pool. What are some best practices in terms of this task returning progress or intermediate results? Are there any libraries that provide this functionality? EDIT: To clarify, I'm talking about reporting progress to other code, not to the user. Normally I would use SwingWorker, but I'm working with a Java/Groovy backend for a Grails app, and I'm unsure how that would behave in a headless server

java executorservice persist queue

无人久伴 提交于 2019-12-06 15:37:05
I implemented the Spring-TaskExecutor (which is the equivalent of the JDK 1.5's Executor.) to process notifications notifications receiving from external systems. Interface with only one method: public interface AsynchronousService { void executeAsynchronously(Runnable task); } and the corresponding implementation: public class AsynchronousServiceImpl implements AsynchronousService { private Executor taskExecutor; @Override public void executeAsynchronously(Runnable task) { taskExecutor.execute(task); } @Required public void setTaskExecutor(Executor taskExecutor) { this.taskExecutor =

用ExecutorService&cyclicBarrier&countDownLatch实现...

三世轮回 提交于 2019-12-06 15:35:43
这个博客介绍的不错: http://my.oschina.net/jielucky/blog/157946 http://my.oschina.net/adwangxiao/blog/110188 我再顺着这个博客往下写: 赛马是个不错的多线程场景,包括所有赛马都准备好,然后指挥官喊预备跑部分,然后所有赛马跑到了,关闭所有跑道两部分,这个场景可以很好的运用多线程。如下图所示. package com.xue.gang.barrier; import java.util.concurrent.BrokenBarrierException; import java.util.concurrent.CountDownLatch; import java.util.concurrent.CyclicBarrier; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class CyclicBarrierMutiRunner { public static void main(String args[]) throws InterruptedException{ final int size = 10; ExecutorService

Java example of using ExecutorService and PipedReader/PipedWriter (or PipedInputStream/PipedOutputStream) for consumer-producer

邮差的信 提交于 2019-12-06 14:58:57
问题 I'm looking for a simple producer - consumer implementation in Java and don't want to reinvent the wheel I couldn't find an example that uses both the new concurrency package and either of the Piped classes Is there an example for using both PipedInputStream and the new Java concurrency package for this? Is there a better way without using the Piped classes for such a task? 回答1: For your task it might be sufficient to just use a single thread and write to the file using a BufferedOutputStream

Android thread runnable performance

强颜欢笑 提交于 2019-12-06 05:49:59
问题 I'm wondering about performance and cpu/ram requirements for 2 different methods of starting runnables I have some code that collects sensor data every 10ms and inserts the values into a database on a background thread (using a single thread executor). Executor service is created as follows: executor = Executors.newSingleThreadExecutor(); One way to do that would be something like... public void onSensorChanged(SensorEvent event) { //get sensor values //insert into database executor.execute

How can I implement or find the equivalent of a thread-safe CompletionService?

 ̄綄美尐妖づ 提交于 2019-12-06 05:19:33
I have a simple web service running inside a Tomcat container, which by nature is multi-threaded. In each request that comes into the service, I want to make concurrent calls to an external service. The ExecutorCompletionService in java.util.concurrent gets me partly there. I can provide it a thread pool, and it will take care of executing my concurrent calls and I will be notified when any of the results are ready. The code to process a particular incoming request might look like: void handleRequest(Integer[] input) { // Submit tasks CompletionService<Integer> completionService = new

How to get optimal bulk insertion rate in DynamoDb through Executor Framework in Java?

不打扰是莪最后的温柔 提交于 2019-12-06 05:02:15
I'm doing a POC on Bulk write (around 5.5k items) in local Dynamo DB using DynamoDB SDK for Java. I'm aware that each bulk write cannot have more than 25 write operations, so I am dividing the whole dataset into chunks of 25 items each. Then I'm passing these chunks as callable actions in Executor framework. Still, I'm not having a satisfactory result as the 5.5k records are getting inserted in more than 100 seconds. I'm not sure how else can I optimize this. While creating the table I provisioned the WriteCapacityUnit as 400(not sure what's the maximum value I can give) and experimented with

newFixedThreadPool() vs newCachedThreadPool() [duplicate]

依然范特西╮ 提交于 2019-12-06 03:16:26
This question already has an answer here: Executors.newCachedThreadPool() versus Executors.newFixedThreadPool() 8 answers In case newCachedThreadPool() as per creates a thread pool that creates new threads as needed, but will reuse previously constructed threads when they are available whereas in case of newFixedThreadPool(int size) specify size to create the thread pool with size specified. Why isn't newFixedThreadPool(int size) implemented in newCachedThreadPool() fashion where thread pool creates the new thread only when required and will limit the thread to size? Any clarrification on the

Does Java provide an ExecutorService which allows a worker to execute on the same thread?

感情迁移 提交于 2019-12-06 03:16:18
问题 I am looking for an implementation of ExecutorService which will provide the following semantics. Each thread is occupied by a 'worker' that performs some task based on an input. Each worker is guaranteed to only execute in a single thread, thus, it should be allowed to maintain state from task to task, without the overhead of synchronisation, since it would be synchronising with itself, in a single thread. So let's say I have 100 inputs, and 10 workers, I would like to be able to write