Java multi-thread switching context vs submit new task and solution for monitoring a queue

• About switching context (synchronizing with wait/notify) between threads and re-submit a task (Callable/Runnable) to Executor service which is better for performance? as I know switching context need to save/reload thread data but if I re-submit a task to an Executor service, JVM need to re-allocate stack for the submitted task so I think it has same cost with switching context?

• I design a task queue for worker threads put tasks to that and a monitor thread to take the tasks in the queue, submit the tasks to a thread pool (executor service). But I considering about when does the monitor thread work?
  Option 1: Using thread "wait" for monitor thread and worker thread will notify the monitor thread after they put task to the queue.
  Option 2: Using a scheduler executor service for monitor thread to check the queue.
  -> Which option is better (for speed, performance) and with option 2: how often to check the queue is the best?

many thanks for your help

1. An executor is usually backed by a thread pool. So the stacks are already allocated. Furthermore, a context switch will only take place if the same CPU core has to execute both threads. Modern CPUs have multiple cores, so there would be no context switch involved.

   Having said that, there is surely some overhead in transferring work to another thread. So tasks should be sufficiently coarse-grained and there should be other work that the main thread can perform in the meantime for the pool to be beneficial.

2. There is no need to have a monitor thread if the queue itself is synchronized. Have a look at ArrayBlockingQueue for example; producers can call the put() method (which blocks when no space in the queue is available), and consumers (threads in the pool) call take(), which blocks when no work is available. This is how ThreadPoolExecutor is implemented (to be precise, it actually calls offer(), so by default doesn't block on the producer side).