Is RestTemplate thread safe?
Is a Spring RestTemplate
thread-safe? That is
- Is a
RestTemplate
a Strategy object that multiple connections can safely share. or - Is a
RestTemplate
a connection object (like a data-base connection), which can not be shared while in use, and requires creation afresh, or pooling, for each connection.
RestTemplate
is thread safe (emphasis added):
Conceptually, it is very similar to the
JdbcTemplate
,JmsTemplate
, and the various other templates found in the Spring Framework and other portfolio projects. This means, for instance, that theRestTemplate
is thread-safe once constructed
Objects of the RestTemplate
class do not change any of their state information to process HTTP: the class is an instance of the Strategy design pattern, rather than being like a connection object. With no state information, there is no possibility of different threads corrupting or racing state information if they share a RestTemplate
object. This is why it is possible for threads to share these objects.
If you examine the source code of RestTemplate
you will see that it does not use synchronized
methods or volatile
fields to provide thread-safety after construction of the object. So it is not safe to modify a RestTemplate
object after construction. In particular, it is unsafe to add a message converter.
To provide it with a list of message converters you must do one of the following:
- Use the
RestTemplate(List<HttpMessageConverter<?>> messageConverters)
constructor. As the internal list ofmessageConverters
isfinal
, this safely publishes the list of message converters. - Use the
setMessageConverters(List<HttpMessageConverter<?>> messageConverters)
mutator and then safely-publish the changedRestTemplate
object. Using a Spring bean definition that has a<property name="messageConverters"><list>...
does this, as the bean will be safely published by the thread setting up the container in most practical use cases. - Use
List.add
on the reference returned bygetMessageConverters()
and then safely publish the changedRestTemplate
object. However, the documentation forRestTemplate
does not explicitly state that it returns a reference that can be used to alter the list of message converters. The current implementation does, but possibly the implementation might be changed to return aCollections.unmodifiableList
or a copy of the list. So it might be better not to change it this way.
Note that the first case is the only means of setting up the message converters when constructing the object, so it is correct to say that it "is thread safe once constructed".
The class is part of the Spring Framework, so in almost all practical cases objects of the class will be set up as part of a Spring Application Context, using the first (dependency injection using a constructor) or second (dependency injection using a setter) methods, and so would be guaranteed to be safely published to multiple threads.
It is thread safe from the library's point of view. For instance, the getMessageConverters() is public Which means that if someone gets hold on the list and modifies it outside of the purpose of the library then it will cause issues (and even the setter method, if it's called at any moment after RestTemplate instantiation - and while being used by other threads obviously, boom!). Which probably is what happened to Ross (not enough reputation to reply to the answer, but I'm backing up both the thread-safe and not thread-safe arguments)