Hi, I’m new in Kotlin and also new CS student However I trying hard to follow the back-end Developer path and studying Data Structures and I wondered if kotlin have thread safe classes like java or not such as vector class , hashtable and so on… , thanks in advance.
Kotlin can use any java class as long as you target the jvm (this is the default). For that reason the kotlin standard library generally doesn’t provide those classes itself.
thanks a lot ,I totally understand this , but I don’t understand how could it be possible that kotlin supported by jvm and it’s standard library doesn’t support or provide those classes ? could you elaborate more ?
appreciate this so much .
For things like HashTable, Java docs recommends using ConcurrentHashMap instead.
I thought thread-safe collections had fallen out of favor? At least I remember reading somewhere that you should try not to use them and instead synchronize the usage points.
Of course, if you’re worried about thread-safety of some data than that data is probably the infamous “shared mutable state”. It might be a sign to considering changing the design to avoid shared mutable state if synchronizing the usage points is tedious.
Kotlin’s stdlib is small. It’s a major goal of Kotlin not to replace Java, but to integrate and interop with Java code. If there’s a Java library already available, you should use that instead of inventing a completely new wheel. And if I have an existing Java library, I should be able to add Kotlin code along side it without introducing a large stdlib. You’re somewhat expected to use the JVM stdlib (or other common platform specific libraries) in your Kotlin code.
The Kotlin stdlib has grown over the years but even still the goal is not to include everything–a lot of library additions are done as separate libraries (Kotlinx libraries). Even things such as time keeping, coroutines, and serialization aren’t included in the core stdlib.
It sounds like the memory model of native will lift that restriction in the future, so maybe Kotlin thread safe collections will make more sense then but mutable state is still frowned upon and even without such collections, wrapping the existing collections with synchronization primitives is an easy work-around for many use cases.
If your intereseted in Kotlin vision about concurrency, I recommend you to start by reading matching reference doc section (coroutines). The shared mutable state section should give you a good introduction about multi-thread access.
The original Java thread-safe collections were never really a good idea. They were eventually replaced with non-thread-safe versions like ArrayList and HashMap, and these are the ones that everyone uses today.
The problem with the original collection set is that using a thread-safe collection does not make your program thread-safe, so when you need thread-safety, you have add an additional layer of synchronization anyway. The synchronization built into the collections themselves then becomes useless overhead.
Hmmm. I agree that making the standard, general-purpose collections thread-safe wasn’t justified. (Or at least, conditionally thread-safe; as you say, there are still dangerous patterns of access.) The compromises you have to make (in performance and/or functionality) aren’t justified for all code.
However, threading support is important, and the Java standard library does contain some thread-safe collections: most notably, ConcurrentHashMap — and an invaluable class it is! It takes a lot more memory than a normal HashMap, so it’s not so suitable as a general-purpose implementation. But it has amazing concurrency behaviour. (All operations are thread-safe; retrieval operations don’t lock and usually don’t block; iterators &c are safe and reflect the state of the map at one moment; and it provides extra methods for atomic actions such as compare-and-set, conditional replace, put if absent, &c.)
You wouldn’t use those all the time; but when you need them (and know how to use them), they’re invaluable.