Thread Magic Tricks: 5 Things You Never Knew You Can Do with Java Threads

what are some of the least known facts and use cases for java threads?

some people like mountain climbing, others do sky diving. me, i like java. one of the things i love about it is that you never stop learning. the tools you use on a daily basis can often reveal a whole new side to them, with methods and interesting use cases you haven't had a chance to see yet. like threads for example. actual threads. or better put, the thread class itself. concurrent programming never stops posing challenges when we're dealing with high scalability systems, but now we'll talk about something a bit different.

in this post you’ll see some of the lesser known yet useful techniques and methods that threads support. whether you’re a beginner, advanced user or an expert java developer, try to see which of these you already know and what comes off as new to you. is there something else about threads you feel worth mentioning? i’d love to hear about it in the comments below. let’s get started.

beginner

1. thread names

each thread in your app has a name, a simple java string that’s generated for it when the thread is constructed. the default name values go from "thread-0" to "thread-1", "thread-2" and so on. now comes the more interesting part - threads expose 2 ways you can use to set their names:

1. the thread constructors, here's the simplest one:

class suchthread extends thread {
    public void run() {
         system.out.println ("hi mom! " + getname());
     }
} 
suchthread wow = new suchthread("much-name"); 

2. the thread name setter:

wow.setname(“just another thread name”); 

right, thread names are mutable. so other than setting a custom name when we’re instantiating them, we can change it during runtime. the name field itself is set as a simple string object. this means it can go up to 2³¹-1 characters long (integer.max_value). more than enough i'd say. please note that this name doesn't act like a unique id, so threads can share the same name. also, don't try passing null as a name unless you want an exception to be thrown ("null" is ok though, i'm not judging!).

using thread names for debugging

so now that you have access to thread names, following some naming conventions of your own could make your life much much easier when something bad happens. "thread-6" sounds a bit heartless, i’m sure you can think of a better name. couple this with a self assigned transaction id when handling user requests, append it to the thread’s name and you’ve considerably cut down your error solving time.

a good practice to keep here is making sure you generate a uuid at every thread’s entry point to your app, and keep it consistent as the request travels between your nodes, processes and threads. let’s take a look at this example, one of the worker threads in a certain thread pool hangs for too long. you run jstack to take a closer look and then you see this:

“pool-1-thread-1″ #17 prio=5 os_prio=31 tid=0x00007f9d620c9800 nid=0x6d03 in object.wait() [0x000000013ebcc000]

ok, "pool-1-thread-1", why so serious? let’s get to know you better and think of a more suitable name:

[java]

thread.currentthread().setname(context + tid + params + current time, ...); 

[/java]

now when we run jstack again, things look much brighter:

”queue processing thread, messageid: ab5cad, type: analyzegraph, queue: active_prod, transaction_id: 5678956, start time: 30/12/2014 17:37″ #17 prio=5 os_prio=31 tid=0x00007f9d620c9800 nid=0x6d03 in object.wait() [0x000000013ebcc000] 

we know what the thread is doing, when it got stuck, and we also have the transaction id that started it all. you can retrace your steps, reproduce the error, isolate and solve it. to learn more about cool ways to use jstack you can check out this post right here .

2. thread priorities

another interesting field threads have is priority. a thread’s priority is a value between 1 (min_priority) to 10 (max_priority), and the default value for your main thread is 5 (norm_priority). each new thread gets the priority of its parent, so if you're not playing with it manually, all your thread priorities are probably set to 5. this is also an often overlooked field of the thread class, and we can access and manipulate it through the methods getpriority() and setpriority() . there’s no way to set this in the thread constructor.

who needs priorities anyhow?

of course not all threads are created equal, some require immediate attention from your cpu while others are just background tasks. priorities are used to signal that to the os thread scheduler. at takipi, where we develop an error tracking and analysis tool, the thread that handles new exceptions for our users gets a max_priority, while threads that handle tasks like reporting new deployments are given a lower priority. one might expect that threads with a higher priority get more time from the thread scheduler working with your jvm. well, that's not always the case.

each java thread opens a new native thread on the os level, and the java priorities that you set are translated to native priorities in a different way for each platform. on linux, you'll also have to include the "-xx:+usethreadpriorities" flag when running your app for them to be considered. with that said, thread priorities are still just recommendations that you provide. compared to native linux priorities, they don't even cover the whole spectrum of values (1..99, and the effects of thread niceness that range between -20..20). the main takeaway is the importance of keeping your own logic that would ensure your priorities are reflected in the cpu time each thread gets, but it's not recommended to rely solely on priorities.

advanced

3. thread local storage

this one is a bit different than the other creatures we talked about here. threadlocal is a concept that’s implemented off the thread class ( java.lang.threadlocal ), but stores unique data for each thread. as it says on the tin, it provides you with thread local storage, meaning you can create variables that are unique to each thread instance. similar to the way you would have a thread name or priority, you can create custom fields that act as if they're members of the thread class. isn’t that cool? but let’s not get too excited , there are some caveats ahead.

it’s recommended to create a threadlocal in one of two ways: either as a static variable or part of singleton where it doesn't have to be static. note that it lives on the global scope, yet acts local to each thread that’s able to access it. here’s an example of a threadlocal variable holding a data structure of our own for easy access:

public static class criticaldata {
     public int transactionid;
     public int username;
}
public static final threadlocal<criticaldata> globaldata =
     new threadlocal<criticaldata>(); 

once we have a threadlocal in our hands, we can access it with globaldata.set() and globaldata.get() .

global? it must be evil

not necessarily. a threadlocal variable can keep a transaction id. this can come in handy when you have an uncaught exception bubbling up your code. a good practice is to have an uncaughtexceptionhandler in place, which we also get with the thread class but have to implement ourselves. once we reach that stage, there aren’t many hints as to what actually got us there. we’re left with the thread object and can’t access any of the variables that go us there as the stack frames shut down. in our uncaughtexceptionhandler, as the thread takes its last breaths, threadlocal is pretty much one of the only things we have left.

we can do something in the spirit of:

system.err.println("transaction id " + globaldata.get().transactionid);

and just like that we added some valuable context to the error. one of the more creative ways to use threadlocal is by allocating a designated chunk of memory to be used as a buffer over and over by a worker thread. this can become useful depending on which side you're on in the memory vs. cpu overhead tradeoff of course. that said, the thing to look out for is abuse of our memory space. threadlocal exists for a specific thread as long as it’s alive and will not be garbage collected unless you free it or the thread dies. so you better be careful when you use it and keep it simple.

4. user threads and daemon threads

back to our thread class. each thread in our app receives either a user or a daemon status. in other words, a foreground or a background thread. by default, the main thread is a user thread and each new thread gets the status of the thread that created it. so if you set a thread as daemon, all the threads it creates will be marked as daemon as well. when the only threads left running in your app are of daemon status, the process closes. to play around, check and change a threads status we have the boolean .setdaemon(true) and .isdaemon() methods.

when would you set a daemon thread?

you should change a thread’s status to daemon when it’s not critical for it to end so the process could close. it takes off the hassle of closing the thread properly, stopping everything at once and let’s it end quickly. on the other hand, when there’s a thread that runs an operation that must end properly or else bad things will happen, make sure it's set as a user thread. a critical transaction could be, for example, a database entry or completing an update that can't be interrupted.

expert

5. java processor affinity

this part takes us closer to the hardware, where the code meets the metal. processor affinity allows you to bind threads or processes to specific cpu cores. this means that whenever that specific thread executes, it would run exclusively on one certain core. normally what would happen is that the os thread scheduler would take on this role according to its own logic, possibly taking the thread priorities we mentioned earlier into account.

the bargaining chip here is the cpus cache. if a thread would only run on one specific core, it's more likely it will get to enjoy having all its data ready for it on the cache. when the data is already there, there’s no need to reload it. the micro-seconds you save can be put to better use and the code will actually run on that time, making better use of the allocated cpu time it got. while some optimizations do exist on the os level, and the hardware architecture also has an important role of course, using affinity can eliminate the chance of a thread switching cores.

since many factors are in play here, the best way to determine how processor affinity would affect your throughput is to embrace the habit of testing. while it may not always be significantly better, one of the benefits you might experience is a steady throughput. affinity strategies can go down to a surgical level, depending on what there is to gain. the high frequency trading industry would be one of the places where these kind of things matter most.

testing processor affinity

java doesn’t have native support for processor affinity but that’s not the end of the story of course. on linux, we can set a process affinity using the taskset command. say we have a java process running and we want to pin it to a specific cpu:

taskset -c 1 "java abouttobepinned"

or if its already running:

taskset -c 1 <pid>

now, to get down to the thread level we'll need to insert some new code. luckily, there’s an open-source library that would help us do just that: java-thread-affinity . written by peter lawrey at openhft, this is probably the most straightforward way to do this. let’s see a quick example of pinning a thread, more of this is available on the library’s github repo:

affinitylock al = affinitylock.acquirelock();

and that’s it. more advanced options for acquiring the lock - taking into account different strategies for choosing the specific core - are available on github.

conclusion

we’ve seen 5 ways to look at threads: thread names, thread local storage, priorities, daemon threads and affinity. hope this helped shed a new light on the things you deal with on a daily basis, and would be glad to hear your comments! what other thread handling methods could fit in?