Singleton and Multithread in SpringBoot. Is it really multi thread?

Since I am not working specifically on multi threads, the questions can be low level or even silly, please excuse me =)

Here is my code call flow like;

MessageNotificationJobExecutionConfig -> AsyncMessageNotificationJobExecutor -> NotificationJobExecutor.execute()

MessageNotificationJobExecutionConfig (finds the objects to process) and calls AsyncMessageNotificationJobExecutor inside the loop

AsyncMessageNotificationJobExecutor has @Async("messageNotificationTaskExecutor") annotation over the execute() method.

AsyncMessageNotificationJobExecutor.execute() method calls NotificationJobExecutor.execute()

messageNotificationTaskExecutor is an instance of ThreadPoolTaskExecutor

Here is my question;

If am not wrong as default NotificationJobExecutor has a singletone instance.

Even if AsyncMessageNotificationJobExecutor work async and use thread pool task executor, all thread call only NotificationJobExecutor instance (singletone).

I am not sure, I may misunderstand that Thread_1 calls NotificationJobExecutor.execute() and until this thread finish its job other thread wait for Thread_1. Is my inference correct ?

I think even if it looks multi thread actually it works singletone

@Component("messageNotificationTaskExecutor")
public class MessageNotificationThreadPoolTaskExecutor extends ThreadPoolTaskExecutor {

    @Value("${message.notification.task.executor.corePoolSize}")
    Integer corePoolSize;

    @Value("${message.notification.task.executor.maxPoolSize}")
    Integer maxPoolSize;

    @Value("${message.notification.task.executor.queueCapacity}")
    Integer queueCapacity;

    public MessageNotificationThreadPoolTaskExecutor() {
        super();
    }

    @PostConstruct
    public void init() {
        super.setCorePoolSize(corePoolSize);
        super.setMaxPoolSize(maxPoolSize);
        super.setQueueCapacity(queueCapacity);
    }

}

@Configuration
public class MessageNotificationJobExecutionConfig {

	protected Logger log = LoggerFactory.getLogger(getClass());

	@Autowired
	AsyncMessageNotificationJobExecutor asyncMessageNotificationJobExecutor;

	@Autowired
	MessageNotificationThreadPoolTaskExecutor threadPoolTaskExecutor;

	@Autowired
	JobExecutionRouter jobExecutionRouter;

	@Autowired
	NotificationJobService notificationJobService;

	private Integer operationType = OperationType.ACCOUNT_NOTIFICATION.getValue();

	@Scheduled(cron = "${message.notification.scheduler.cronexpression}")
	public void executePendingJobs() {
		
		List<NotificationJob> nextNotificationJobList = notificationJobService.findNextJobForExecution(operationType, 10);

		for (NotificationJob nextNotificationJob : nextNotificationJobList) {
			if (threadPoolTaskExecutor.getActiveCount() < threadPoolTaskExecutor.getMaxPoolSize()) {
				asyncMessageNotificationJobExecutor.execute(nextNotificationJob);
			}
		}
	}
}

@Service
public class AsyncMessageNotificationJobExecutor {
	
	@Autowired
	NotificationJobExecutor notificationJobExecutor;

	@Autowired
	NotificationJobService notificationJobService;
	
	@Async("messageNotificationTaskExecutor")
	public void execute(NotificationJob notificationJob) {
			notificationJobExecutor.execute(notificationJob);
	}
}

@Component
public class NotificationJobExecutor implements JobExecutor {
	
	@Override
	public Integer getOperationType() {
		return OperationType.ACCOUNT_NOTIFICATION.getValue();
	}
	
	@Override
	public String getOperationTypeAsString() {
		return OperationType.ACCOUNT_NOTIFICATION.name();
	}
	
	@Override
	public void execute(NotificationJob notificationJob) {
		// TODO: 20.08.2020 will be execute 
	}
	
}

In the scenario you created you have all singleton instances. But the flow looks something like this:

1. call to executePendingJobs in MessageNotificationJobExecutionConfig
2. iterate over each NotificationJob sequentially (so this is waiting)
3. call to execute in AsyncMessageNotificationJobExecutor which will add a execution to the messageNotificationTaskExecutor sequential (thus blocking) to the thread pool
4. execute the job created in step 3 in a separate thread (so this actually executes your method in AsyncMessageNotificationJobExecutor
5. a blocking call to the execute method in NotificationJobExecutor

The 'magic' happens in step 3, where rather then executing the method Spring will add a job to the messageNotificationTaskExecutor which wraps the call to step 4. This causes the call for step 4 to happen asynchronous and thus multiple calls to the same instance can occur at the same time. So make sure this object is stateless.