Notes on Java Daemon Thread

I’m going to work on Daemon thread in my new job, but I have no idea what it is. This post summarizes some of the key points from a stackoverflow post.


First, let’s look at daemon threads in Unix. Simply put, they are threads running in the background that answer requests for services. You can check more of it on Wikipedia.

There are two types of Java thread:

  • Normal/User thread: Generally all threads created by programmer are user thread (unless you specify it to be daemon or the parent thread spawning the new thread is a daemon thread). The main thread is by default a non daemon thread.
  • Daemon thread: it is similar (I don’t know if I can say that. Correct me if I’m wrong please). Daemon threads are like a service providers for other threads or objects running in the same process as the daemon thread (In other words, they may serve the user threads). They are typically used for background supporting tasks.

Points to Note about Java Daemon Threads:

  • (needs verification) It has very low priority and only executes when no other threads of the same program is running
  • When there are no more user threads (meaning that only daemon threads are running in a program), the JVM will ends the program and exit. This is reasonable. If there are no one to serve any more, why keep the servants? (This is my own thoughts) 
  • When the JVM halts, all daemon threads are abandoned. The “finally blocks“ are not executed and stacks are not unwound (not sure what this means).
  • Daemon threads usually have an infinite loop in its run() method that waits for the service request or performs the tasks of the thread.
  • We can set a thread to be daemon through the setDaemon() method but we can only do that before the start of the thread.
  • We can check if a thread is a user thread or daemon thread using isDaemon() thread.

Examples of Java Daemon Threads:

  • Garbage collection. It runs in the background, claiming resources from unwanted objects.
  • A good Java code example from that post, reposted on gist

Things to check…

  • Non-daemon threads (default) can even live longer than the main thread.

Java Multithreading Notes From Lecture Two

This is part of the notes from an online course (Java Multithreading) I’m taking on Udemy. Nothing complicated.

In theory it is possible that on some system a Java thread may ignore changes to its own data from other threads. If the changes are not made inside its own thread, it may have no effect. We can call it caching variable in thread.

To prevent such thing, we can add the keyword volatile to the variable that may be changed by other threads and guarantee that changes can be seen.

An example on gist.


Java Multithreading Notes From Lecture One

This is part of the notes from an online course (Java Multithreading) I’m taking on Udemy. Nothing complicated.


There are normally three ways to create threads (Examples on gist):

  • Create a class that extends the Thread class
  • Create a class that implements the Runnable interface
  • Create a Thread anonymously

Whichever we choose to use, we must override or implement the public void run method.


All Java programs have a main thread, but we can create and invoke other threads from the main thread.

To do that, we need to call the start() method of each thread we want to invoke from main thread. It will look for the run() method and run that in its own special thread, not in the main thread (refer to the in the gist).

The start() method will return immediately so the main thread will continue its execution of the next line of code.

However, if we accidentally call the run() method of those threads, then the method run() will be executed in the main thread, not in its own special thread! So be careful.


Some thoughts on the Golang concurrency and channel

I just tried the Golang recently. It’s easy to pick up if you have some C and OOP background. The only thing I’m not completely clear is the go concurrency.

The relationship between goroutine and threads could be N to 1 where N >= 1. That is to say with only one thread you can run several goroutines concurrently (switching between them in a very short interval which makes you feel like they are executing simultaneously. It’s not parallelism since you only have one thread.)

The goroutines can communicate through channels. A channel call may be blocked and the goroutine making that call will be set to waiting, but the thread running the goroutine WILL NOT BLOCK (unless the goroutine makes a BLOCKING SYSTEM CALL. This will cause the thread to block.) and move on to other runnable goroutines. Later, when the channel block is cleared, the thread will come back to run the previous channel blocked goroutine.

A goroutine can yield back to the thread in the following ways (check this post on stackoverflow):

  • The select statement can yield control back to the thread.
  • sending on a channel can yield control back to the thread.
  • Doing IO operations can yield control back to the thread.
  • runtime.Gosched() explicitly yields control back to the thread.

Let’s look at some examples to illustrate the ideas above (wordpress does not support Golang…).

The output would be:


One possible execution order could be (as suggested on stack overflow):

  1. Main function creates two go routines.
  2. The scheduler chooses to switch to the go routine display immediately and print out the message. Then display is in a channel block since the receiver of the channel call is not ready yet.
  3. The scheduler chooses to run the sum goroutine next. It prints out the sum and block on channel call (not sure if I’m right about this part).
  4. The scheduler switches back to main since it is the only one that is not channel blocked. <-c wants to receive data and the sender is also ready (from display). So both side is ready and the execution continues. Well we print out true and ends the program. The data “false” from the sum goroutine never got sent.

If you are expecting only the output from display, you can do the following things:

The program above uses only one thread. You can explicitly set the number of threads to run the program by using runtime.GO.MAXPROCS()


Here we have two threads running two goroutines. One executes display (we call it ThreadA) while the other executes the sum (we call it ThreadB). Since sum takes longer, display reaches the channel call (blocked) first. So ThreadA looks for another routine that is runnable. Ah main is open (sum is still executed by ThreadB). In main, it receives data from channel. Since we have both side ready, main continues execution and exit the program regardless of the status of the sum routine.


Another way to do it is to use the time.Sleep() in the sum routine.


Once again we only have one thread. While the thread executes goroutine sum, it finds out the time.Sleep call. This will cause the routine to hang and yield the control back to the Go Scheduler.

  1. Main creates two go routines.
  2. Go scheduler executes display and block on channel call.
  3. Go scheduler executes sum. Sum yields control back to the scheduler because of the time.Sleep call.
  4. Scheduler executes main. Print out the bool value from the channel and exits.

Note that the execution order above is just one possibility. There could be other orders. Another very good post on stack overflow:

In the latest version, the execution context can switch on IO functions. So the real execution order for the code above can have more possibilities.