Skip to content

Tag: thread-safety

Is the Jackson2JsonMessageConverter class thread-safe?

I’m using this class and I’m wondering whether it’s thread safe: The docs don’t make any claims about this. I skipped through the code and found no signs it’s not thread-safe. It’s using an ObjectMapper internally, which is thread-safe according to docs: Mapper instances are fully thread-safe provided that ALL configuration of the instance occurs before ANY read

Is replacing one java object reference with another considered thread safe, or are there potential synchronicity issues I’m overlooking?

I’m rolling my own simple caching solution to improve the UX of a lengthy lookup. The basic outline is that I have a class handling all accountId lookups, and another class called AccountListCache with two variables: a timestamp indicating when it was created, and a List object containing a whole bunch of accountId objects. When the lookup is invoked, that

Clock thread in Java

I have been studying about Java Thread recently. I created this simple clock that will display how many seconds have passed. It looked like this Here is the code for the application above (including 2 classes: Main and ClockPanel) The problem is: if i remove the line System.out.println() (as i commented in the code above), the clock will not run.

Does a mutable Java object equal itself? [closed]

Closed. This question needs details or clarity. It is not currently accepting answers. Want to improve this question? Add details and clarify the problem by editing this post. Closed 1 year ago. Improve this question I was thinking about mutable objects and how they’re weird (but very cool). Question: can a mutable object not equal itself? Only caveat here is

Java mmap MappedByteBuffer

Let’s say I’ve mapped a memory region [0, 1000] and now I have MappedByteBuffer. Can I read and write to this buffer from multiple threads at the same time without locking, assuming that each thread accesses different part of the buffer for exp. T1 [0, 500), T2 [500, 1000]? If the above is true, is it possible to determine whether

How can I guarantee a thread is safely unlocking a lock upon termination, while all methods already handle it?

A server project, might run for very long time and create many threads. In the following code I ask myself do i have to protect the lock somehow in addition to an overall try catch in method setData(MyData data): note: assuming its thread-safe, i am not really familiar with other reasons or natural disasters that may cause thread termination, like