J. Bloch in his Effective Java suggests we use an enum-based singleton implementation. For instance:
public enum Application {
INSTANCE;
//methods, fields
}
This implementation is nice in the case of serialization because enums provide us with the capability of serialization by default (and we don't have to be afraid of getting two different instances while deserializing the object).
My question is how this implementation respects multhreading. How to make it thread-safe? What would we probably get if we try to access it from different threads?
The actual enum behavior of instatiating the instance doesn't have an issue with thread safety. However, you will need to make sure that the instance state itself is thread-safe.
The interactions with the fields and methods of Application are the risk--using either careful synchronization and locking, or purely concurrent data and careful verification that other inconsistencies can't happen, will be your best bet here.
Singleton ensures you only have one instance of a class per class loader.
You only have to take care about concurrency if your singleton has a mutable state. I mean if singleton persist some kind of mutable data.
In this case you should use some kind of synchronization-locking mechanishm to prevent concurrent modification of the state and/or use thread-safe data structures.
Related
In an article called Root Cause of Singletons writed by Miško Hevery:
Now, there is one kind of Singleton which is OK. That is a singleton where all of the reachable objects are immutable. If all objects are immutable than Singleton has no global state, as everything is constant.
A singleton always has global state, because all of the design patterns of singleton expose a global reference to the single instance.
But why immutable singleton has no global state?
Since immutable object cannot be reused and are just a use and throw object, improper usage may lead to large amount of garbage, thereby lowering the performance of application.
Singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.
A singleton must be thread-safe if used in multiple threads;
immutable objects is also thread-safe but they are inherently thread-safe.
Think of this kind of Singleton that the author describes as just a static, constant object.
The singleton pattern does not necessarily guarantee immutability. So imagine that you have a Singleton that is used by many other modules/components/objects in your code and its state changes. This could arguably lead to unexpected behavior. Object A leaves the singleton in a state A, but nothing guarantees that the singleton's state won't become B after a while.
I think this is what the author tries to outline here. Example singletons of this kind are configuration objects, or static Maps.
I'm doing a app in android with Rest and observer design pattern, when I do a Rest request I cache the response but some of this response object I want to let the objects in memory permanently until the application is destroyed.
So I have been thinking in create a class with just public static variables (some projects use this kind of class to declare constants Strings) to set them and then I could use it in memory. Something like this:
public class Memory {
public static HashMap<String, PersonDto> people;
// This object could have another complex object as ArrayList or HashMap...
public static LocationsDto locations;
...
}
All I want to know if this could be a bad practice to do what I am trying to solve.
It depends on the usage of these objects. The most important aspect being: is there a possibility of concurrent modification/access? If so, then you should implement some kind of synchronization.
If these objects are guaranteed to be constructed before any access to them and they will not change their state afterwards, then your approach would be fine in terms of synchronization issues.
For instance, if your Dto objects are immutable and the hashmap will not be modified concurrently, than you are safe. If the hashmap needs to support concurrent access/modification, then take a look at the ConcurrentHashMap.
While its not definitively a bad practice, it is usually considered as a design flaw to have global mutable state. You can find a lot of information about why it is so. To me the most important disadvantages are problems with testability and unpredictable program state.
If you are still going to use it, you would also want to synchronise access to the static fields.
In many of the projects I have worked on we often have a lot of classes that map content from one domain model to another. For example from a WSDL generated model to a project specific one.
for example
public class FooBarContentMapper {
public static Foo fromWsToDomain(FooType fooType) {
...
}
}
this can also be a non-static method and the service layer can have a mapper object field instead of calling the static method:
public class FooBarContentMapper {
public Foo fromWsToDomain(FooType fooType) {
...
}
}
I find both ways used a lot, but:
is one of the solutions more efficient in any way?
are any of the solutions considered best practice?
"Is one of the solutions more efficient in any way?"
Define "efficient".
If, by "efficient", you're referring to CPU time and memory requirements, then the "instance" approach can never be more efficient than the "static" approach; at best, it can be as efficient as the static approach, and the difference depends on the frequency of object instantiation, read: how many times are you going to instantiate the "instance" approach.
"Are any of the solutions considered best practice?"
No. The "best practice" here is to match your design to your requirements.
If the mapping operation requires maintaining state, such as dependencies on other services/mappers/whatnot, then going with the "instance" approach makes more sense. One thing you don't want to get into is a world where your application's design consists of singletons that depend on each other. Use the "instance" approach, preferably using an auto-wiring facility such as the Spring Framework or CDI.
If the mapping operation requires no state, and you have an extremely high confidence in that it will never require state in the future, then use the "static" approach - unless you already have an auto-wiring facility at hand, in which case, you might as well choose the "instance" approach with auto-wiring and guarantee that, if the mapping operation requires state in the future, you won't have to alter your design much.
There are other things to consider:
Is your code testable. Mappers are used as collaborators so unit testing the object using the mapper should focus on behavior (i.e is the mapper being used when expected) ?
Is the static class used in more than one place and subject to race condition because the transform method takes a mutable object(remember, stateless static classes are still subject to race condition when taking a mutable object that is referenced by two different threads at same time)?
Does the static object actually share its life-cycle with the object using it?
If the answer is yes to any of these, you should consider switching to instance.
I am working on a problem where I need to load a large number of inputs to a problem, and process those inputs to create a 'problem space' (i.e. build data structures allowing efficient access to the inputs, etc). Once this initialization is complete, a multi-threaded process kicks off which uses the organized/processed inputs extensively in a concurrent fashion.
For performance reasons, I don't want to lock and synchronize all the read operations in the concurrent phase. What I really want is an an immutable object, safe to access by multiple readers simultaneously.
For practical reasons (readability & maintainability) I don't want to make the InputManager a true immutable object (i.e. all fields 'final' and initialized in construction). The InputManager will have numerous data structures (lists and maps), where the objects in each have many circular references to each other. These objects are constructed as 'true' immutable objects. I don't want to have a 14 argument constructor for the InputManager, but I do need the InputManager class to provide a consistent, read-only view of the problem space once constructed.
What I'm going for is 'popsicle immutability' as discussed by Eric Lippert here.
The approach I'm taking relies on using 'package visibility' of all mutating methods, and performing all mutable actions (i.e. construction of the InputManager) within a single package. Getters all have public visibility.
Something like:
public final class InputManager { // final to prevent making mutable subclasses
InputManager() { ... } //package visibility limits who can create one
HashMap<String,InputA> lookupTable1;
...
mutatingMethodA(InputA[] inputA) { //default (package visibility)
//setting up data structures...
}
mutatingMethodB(InputB[] inputB) { //default (package visibility)
//setting up data structures...
}
public InputA getSpecificInput(String param1) {
... //access data structures
return objA; //return immutable object
}
}
The overall idea, if I haven't been clear enough, is that I'll construct the InputManager in a single thread, then pass it to multiple threads who will do concurrent work using the object. I want to enforce this 'two-phase' mutable/immutable object lifecycle as well as possible, without doing something too 'cute'. Looking for comments or feedback as to better ways to accomplish this goal, as I'm sure it's not an uncommon use case but I can't find a design pattern that supports it either.
Thanks.
Personally I'd stay with your simple and sufficient approach, but in case you're interested, there is such a thing as a mutable companion idiom. You write an inner class that has mutators, while reusing all the fields and getters from the enclosing instance.
As soon as you lose the mutable companion, the enclosing instance it leaves behind is truly immutable.
I think you can simply have separate interfaces for your two phases. One for the building part, the other for the reading part. This way, you separate your access patterns cleanly. You can see this as an instance of the interface segregation principle (pdf):
Clients should not be forced to depend upon interfaces that they do not use.
As long as the object is safely published, and the readers cannot mutate it.
"Publication" here means how the creator makes the object available to readers. For example, the creator put it in a blocking queue, and readers are polling the queue.
It depends on your publication method. I'll bet it's a safe one.
I am working on my first mutlithreaded program and got stuck about a couple of aspects of synchronization. I have gone over the multi-threading tutorial on oracle/sun homepage, as well as a number of questions here on SO, so I believe I have an idea of what synchronization is. However, as I mentioned there are a couple of aspects I am not quite sure how to figure out. I formulated them below in form of clear-cut question:
Question 1: I have a singleton class that holds methods for checking valid identifiers. It turns out this class needs to hold to collections to keep track of associations between 2 different identifier types. (If the word identifier sounds complicated; these are just strings). I chose to implement two MultiValueMap instances to implement this many-to-many relationship. I am not sure if these collections have to be thread-safe as the collection will be updated only at the creation of the instance of the singleton class but nevertheless I noticed that in the documentation it says:
Note that MultiValueMap is not synchronized and is not thread-safe. If you wish to use this map from multiple threads concurrently, you must use appropriate synchronization. This class may throw exceptions when accessed by concurrent threads without synchronization.
Could anyone elaborate on this "appropriate synchronization"? What exactly does it mean? I can't really use MultiValueMap.decorate() on a synchronized HashMap, or have I misunderstood something?
Question 2: I have another class that extends a HashMap to hold my experimental values, that are parsed in when the software starts. This class is meant to provide appropriate methods for my analysis, such as permutation(), randomization(), filtering(criteria) etc. Since I want to protect my data as much as possible, the class is created and updated once, and all the above mentioned methods return new collections. Again, I am not sure if this class needs to be thread-safe, as it's not supposed to be updated from multiple threads, but the methods will most certainly be called from a number of threads, and to be "safe" I have added synchronized modifier to all my methods. Can you foresee any problems with that? What kind of potential problems should I be aware of?
Thanks,
Answer 1: Your singleton class should not expose the collections it uses internally to other objects. Instead it should provide appropriate methods to expose the behaviours you want. For example, if your object has a Map in it, don't have a public or protected method to return that Map. Instead have a method that takes a key and returns the corresponding value in the Map (and optionally one that sets the value for the key). These methods can then be made thread safe if required.
NB even for collections that you do not intend to write to, I don't think you should assume that reads are necessarily thread safe unless they are documented to be so. The collection object might maintain some internal state that you don't see, but might get modified on reads.
Answer 2: Firstly, I don't think that inheritance is necessarily the correct thing to use here. I would have a class that provides your methods and has a HashMap as a private member. As long as your methods don't change the internal state of the object or the HashMap, they won't have to be synchronised.
It's hard to give general rules about synchronization, but your general understanding is right. A data-structure which is used in a read-only way, does not have to be synchronized. But, (1) you have to ensure that nobody (i.e. no other thread) can use this structure before it is properly initialized and (2) that the structure is indeed read-only. Remember, even iterators have a remove method.
To your second question: In order to ensure the immutability, i.e. that it is read-only, I would not inherit the HashMap but use it inside your class.
Synchronization commonly is needed when you either could have concurrent modifications of the underlying data or one thread modifies the data while another reads and needs to see that modification.
In your case, if I understand it correctly, the MultiValueMap is filled once upon creation and the just read. So unless reading the map would modify some internals it should be safe to read it from multiple threads without synchronization. The creation process should be synchronized or you should at least prevent read access during initialization (a simple flag might be sufficient).
The class you descibe in question 2 might not need to be synchronized if you always return new collections and no internals of the base collection are modified during creation of those "copies".
One additional note: be aware of the fact that the values in the collections might need to be synchronized as well, since if you safely get an object from the collection in multiple thread but then concurrently modify that object you'll still get problems.
So as a general rule of thumb: read-only access does not necessarily need synchronization (if the objects are not modified during those reads or if that doesn't matter), write access should generally be synchronized.
If your maps are populated once, at the time the class is loaded (i.e. in a static initializer block), and are never modified afterwards (i.e. no elements or associations are added / removed), you are fine. Static initialization is guaranteed to be performed in a thread safe manner by the JVM, and its results are visible to all threads. So in this case you most probably don't need any further synchronization.
If the maps are instance members (this is not clear to me from your description), but not modified after creation, I would say again you are most probably safe if you declare your members final (unless you publish the this object reference prematurely, i.e. pass it to the outside world from the cunstructor somehow before the constructor is finished).