Java Interview question -2

Question 11: How to restrict object creation in Java?

We can simply use a singleton design pattern to do that. here are quick steps to do that —

• Private constructor to restrict instantiation of the class from other classes.

• The private static variable of the same class is the only instance of the class.

• The public static method that returns the instance of the class, this is the global access point for the outer world to get the instance of the singleton class.

Question 12: Scenario, you must create a cached thread pool using the executor framework, but you don’t know the capacity or number of threads needed to achieve that task. how will you determine how many threads you will need based on your requirement? is there any mechanism in the executor’s framework to know its capacity?

It is open ended question and interviewer is checking your though process and protential solution which you can suggest.

But, here we will see 2 implementations of ExecutorService —

1. Cached Thread Pool

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, 
      new SynchronousQueue<Runnable>());
}

Cached thread pools are using “synchronous handoff” to queue new tasks. The basic idea of synchronous handoff is simple and yet counter-intuitive: One can queue an item if and only if another thread takes that item at the same time. In other words, the SynchronousQueue can not hold any tasks whatsoever.

Suppose a new task comes in. If there is an idle thread waiting on the queue, then the task producer hands off the task to that thread. Otherwise, since the queue is always full, the executor creates a new thread to handle that task.

The cached pool starts with zero threads and can potentially grow to have Integer.MAX_VALUE threads. Practically, the only limitation for a cached thread pool is the available system resources.

To better manage system resources, cached thread pools will remove threads that remain idle for one minute.

Let’s see use cases —

The cached thread pool configuration caches the threads (hence the name) for a short amount of time to reuse them for other tasks. As a result, it works best when we’re dealing with a reasonable number of short-lived tasks.

The key here is “reasonable” and “short-lived”. To clarify this point, let’s evaluate a scenario where cached pools aren’t a good fit. Here we’re going to submit one million tasks each taking 100 micro-seconds to finish:

Callable<String> task = () -> {
    long oneHundredMicroSeconds = 100_000;
    long startedAt = System.nanoTime();
    while (System.nanoTime() - startedAt <= oneHundredMicroSeconds);
    return "Done";
};
var cachedPool = Executors.newCachedThreadPool();
var tasks = IntStream.rangeClosed(1, 1_000_000)
          .mapToObj(i -> task).collect(toList());
var result = cachedPool.invokeAll(tasks);

This is going to create a lot of threads that translate to unreasonable memory usage, and even worse, lots of CPU context switches. Both of these anomalies would hurt the overall performance significantly.

Therefore, we should avoid this thread pool when the execution time is unpredictable, like IO-bound tasks.

2. Fixed Thread Pool

public static ExecutorService newFixedThreadPool(int nThreads) {
     return new ThreadPoolExecutor(nThreads, nThreads, 0L, 
                                          TimeUnit.MILLISECONDS, 
      new LinkedBlockingQueue<Runnable>());
}

As opposed to the cached thread pool, this one is using an unbounded queue with a fixed number of never-expiring threads. Therefore, instead of an ever-increasing number of threads, the fixed thread pool tries to execute incoming tasks with a fixed amount of threads. When all threads are busy, then the executor will queue new tasks. This way, we have more control over our program’s resource consumption.

As a result, fixed thread pools are better suited for tasks with unpredictable execution times.

3. Unfortunate Similarities

So far, we’ve only enumerated the differences between cached and fixed thread pools.

All those differences aside, they’re both using AbortPolicy as their saturation policy. Therefore, we expect these executors to throw an exception when they can’t accept and even queue any more tasks.

Let’s see what happens in the real world.

Cached thread pools will continue to create more and more threads in extreme circumstances, so, practically, they will never reach a saturation point. Similarly, fixed thread pools will continue to add more and more tasks in their queue. Therefore, the fixed pools also will never reach a saturation point.

As both pools won’t be saturated, when the load is exceptionally high, they will consume a lot of memory for creating threads or queuing tasks. Adding insult to the injury, cached thread pools will also incur a lot of processor context switches.

Anyway, to have more control over resource consumption, it’s highly recommended to create a custom ThreadPoolExecutor:

var boundedQueue = new ArrayBlockingQueue<Runnable>(1000);
new ThreadPoolExecutor(10, 20, 60,SECONDS,boundedQueue, new AbortPolicy());

Here, our thread pool can have up to 20 threads and can only queue up to 1000 tasks. Also, when it can’t accept any more load, it will simply throw an exception.

Question 13: What is the difference between a completable future and a callable and runnable future?

The Future interface was added in Java 5 to serve as a result of an asynchronous computation, but it did not have any methods to combine these computations or handle possible errors.

Java 8 introduced the CompletableFuture class. Along with the Future interface, it also implemented the CompletionStage interface. This interface defines the contract for an asynchronous computation step that we can combine with other steps.

the CompletableFuture class implements the Future interface, so we can use it as a Future implementation, but with additional completion logic.

The Runnable interface is a functional interface and has a single run() method that doesn’t accept any parameters or return any values.

The Callable interface is a generic interface containing a single call() method that returns a generic value V.

Question 14: Program — WAP using stream java 8?

List<Integer> arr = Arrays.asList(1,2,3,4,5,6,7,8,9,10);

from the above list, you have to find an average of even numbers using java 8.

package learning.functionalprogramming;

import java.util.Arrays;
import java.util.List;
class EvenAverage {
    public static void main(String[] args) {
        List<Integer> arr = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
        System.out.println(evenAvg(arr));
    }
    private static double evenAvg(List<Integer> list) {
        return list
                .stream()
                .filter(x -> x % 2 == 0)
                .mapToInt(x -> x)
                .average()
                .orElseGet(() -> 0.0);
    }
}
/**
 * Output: 6.0
 */

Question 15: What is parallel processing in java 8, and what are its uses?

By default, any stream operation in Java is processed sequentially, unless explicitly specified as parallel.

Sequential streams use a single thread to process the pipeline. Any stream in Java can easily be transformed from sequential to parallel. We can achieve this by adding the parallel method to a sequential stream or by creating a stream using the parallelStream method of a collection:

Parallel streams enable us to execute code in parallel on separate cores. The final result is the combination of each individual outcome.

However, the order of execution is out of our control. It may change every time we run the program

Question 16: What are the CQRS and Event Sourcing microservice design patterns?

We’ll explore the basic concepts of Command Query Responsibility Segregation (CQRS) and Event Sourcing design patterns.

While often cited as complementary patterns, we’ll try to understand them separately and finally see how they complement each other.

1. Basic Concepts

We’ll first understand these patterns theoretically before we attempt to implement them. Also, as they stand as individual patterns quite well, we’ll try to understand without mixing them.