Java Interview : Threads

Java came up with multi threading long time back, still the kind of response it invokes when this topic raises its head during interviews is not very encouraging. If you have attended an java interview, a couple of suppose to be very smart guys also know as lead developers will shower you with questions on multi threading, grilling you down to make sure what you are talking about, even asking you to write fork-join snippets to solve hadoop use cases.

But if you are hired and you write a piece code using executor framework, you will be seen with suspicion generally reserved for people with casual shoes at cocktail parties.

So here is post to start out thinking about threads.

So a path of execution in java is known as a thread, appropriately an instance of Thread class. The main method runs in its own thread and starts up the program execution. If you implement the Runnable interface, you can run in a thread of you own. The Runnable interface has a run() method you implement your functionality in it and call the Threads start() method to fire it up.

The threads are served in two flavors, user and daemon threads. User threads are generally the run method implementations done by the user and executes its code and finishes, if not interrupted by an external event. Daemon threads are like background services in Unix which have low priority. Its like the mopping up operations you do once the main operations are over. Logging is a good example of the daemon thread, it exits if no user threads running anymore. SetDaemon() makes a thread a daemon thread.

If you want to have a idea of process and thread there is a previous post on the topic.

Complexity arises when multiple threads are capable of manipulating a shared resources, care needs to be taken to make sure untoward implications of these actions do not effect the functionality of the application. This makes the situation scary for the reviewers and hence its better to reject you code than get in the chain of responsible guys who had a look at your buster. Asking questions in interviews to prove yourself better than the candidate and writing good quality functioning code looks to be two points worth pondering.