OCP - 3

It declares the checked InterruptedException which must be handeled

It simplifies the execution of concurrent tasks by abstracting common error-prone operations

It is important to call the shutdown() method. A thread executor creates a non-demon thread on the first task that is executed, so failing to call shutdown will result in you application never terminating.

All Tasks that are queued are executed in the order in which they were added to the executor service

• After construction, an ExecutorService is active, meaning it accepts new tasks and executes tasks.
• After calling shutdown(), an ExecutorService is shutting down, meaning it rejects new tasks and executes tasks.
• After all Tasks are finished,  an ExecutorService is terminated, meaning it rejects new tasks and no tasks are running

• It attempts to stop all running tasks (NO Guarantees)
  • Typical implementations will cancel via Thread.interrupt(), so any task that fails to respond to interrupts may never terminate.
• This method does not wait for actively executing tasks to terminate. Use awaitTermination to do that.
• No new tasks are started and all queued, unexecuted Tasks are returned

• Future<?> submit(Runnable task)
• <T> Future<T> submit(Callable<T> task)
• <T> List<Future<T>> invokeAll(Collection<? extends Callable<T>> tasks) throws InterruptedException
• <T> T invokeAny(Collection<? extends Callable<T>> tasks) throws InterruptedException, ExecutionException

• execute is fire and forget - has no return type. It accepts a Runnable Instance, meaning that the implementation cannot throw a checked exception
• submit returns a Future to access it's result. It accepts a Calleable Instance, meaning that the implementation can throw a checked exception

• It executes the given task synchronously!
  •  Future.isDone() is true for each element of the returned list.
• The result is a list of all task results as a Collection of futures
  • Same order as the original collection

• It executes the given tasks synchronously
• The result is the Result one of th the finished tasks
  • It is not guaranteed that the result of the Task that terminates first is used!
• All unfinished tasks are canceled

• isDone
• isCancelled
• cancel
• V get()
• V get(long timeout, TimeUnit unit)

When the task was completed, threw an exception or was cancelled

• Without a timeout: Retreives the result of a task, waiting endlessly if it is not yet available
• With a timeout: Throws a checked TimeoutException when the result is not ready by the time the timeout is reached

Callable can return a value and allows a throws declaration of Exception

@FunctionalInterface Callable<V> { V call() throws Exception;}

@FunctionalInterface Runnable { void run()}

It can be resulved with an explicit cast:

use((Callable<Integer>)() -> {throws new IOException("");}};

• Blocks until all tasks have completed execution after a shutdown request
• or the timeout occurs
• or the current thread is interrupted
• whichever happens first!

• schedule(Callable<V> callable, long delay, TimeUnit unit)

  • Run after a given delay(Think "setTimeout")

• schedule(Runnable callable, long delay, TimeUnit unit)

  • Run after a given delay (Think "setTimeout")

• scheduleAtFixedRate(Runnable command, long initialDelay, long period, TimeUnit unit)

  • Run after a given delay (Think "setTimeout")

  • Create a new task every period value that passes (Think "setInterval")

• scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)

  • Run after a given delay (Think "setTimeout")

  • Create a delayed task with after the the termination of the previous one

Since they can run ininitely, the result will never be available, making Runnable the only valid option

• ExecutorService newSingleThreadExecutor()
• ScheduledExecutorService newSingleThreadScheduledExecutor()
• ExecutorService newCachedThreadPool()
  • Create new Threads when none available, but reuse existing, unused Thread instances when idle
• ExecutorService newFixedThreadPool(int nThreads)
  • Fixed number of threads
• ScheduledExecutorService ScheduledThreadPool(int nThreads)
  • Fixed number of threads + Scheduling

Only for man short-lived async tasks.

• Monitor using the synchronized keyword = Locking
• Atomic clases that provide atomic operations

• AtomicBoolean
• AtomicInteger
• AtomicIntegerArray
• AtomicLong
• AtomicLongArray
• AtomicReference (Object Reference)
• AtomicReferenceAray

• get
• set
• getAndSet
• incrementAndGet
• getAndIncrement
• decrementAndGet
• getAndDecrement

The creation of the threads is synchronized but not the execution!

Yes, the class object is used for locking

They offer convenience and prevent error prone implementations and avoid unnecessary synchronisation

A memory consitency error occurs, when two threads have incosistent views of what should be the same data. In the context of Collections, a common error is concurrent modification (ConcurrentModificationException)

• ConcurrentHasMap
• ConcurrentLinkedDeque
• ConcurrentLinkedQueue
• ConcurrentSkipListMap
• ConcurrentSkipListSet
• CopyOnWriteArrayList
• CopyOnWriteArraySet
• LinkedBlockingDeque
• LinkedBlockingQueue

The Blocking versions offer additional methods that will wait for a specific amount of time to complete an operation:

eg. boolean offer(E e, long timeout, TimeUnit unit) throws InterruptedException -> Returns false on timeout

eg. E poll(long timeout, TimeUnit unit) throws InterruptedException -> Returns null on timeout

Thei offer sorted (natural ordering) concurrent collections, making them the concurrent counterparts of TreeSet and TreeMap

The underlying data is copied when the collection changes. When using an iterator, the underlying values do not change, eg:

List<Integer> list = new CopyOnWriteArrayList<>(Arrays.asList(4,3,52));
for(Integer item:list){
  list.add(9); // Neither a ConcurrentModification is thrown nor does a infinite loop result
}

They wrap a non-concurrent implementation of a collection in a thread-safe version. This is convenient but less efficient that using a concurrent implementation instead.

Also: These wrapper functions do not synchronize iterators, meaning that you have to use a monitor when iterating over a collection!

Seria streams are ordered whereas parallel streams are not necessarily

Either use .parallel() on an existing stream or use the parallelStream() method on the Collection instance