Well I am not familiar with threads in java, so I am dealing with this problem: I have a singleton object who contains some objects (let say sessions) and each object has a duration time, so that means that after a some time one object is considered expired so it needs to be removed from (a pool - List in singleton) singleton. To do this I decided to have a thread that checks every 5 minutes (or 10 minutes or whatever) and clean up all session in the singleton class. How can I implement such a functionality avoiding any possible deadlock and or time consuming blocks. Thank you in advance.
I wouldn't implement it like that. Instead, I would delete the timed out sessions when a session is asked to the pool (not necessary at each get, though). This is, BTW, what is done by Guava's CacheBuilder, which you could use, since it's simple, tested, and provide useful features.
If you really want to go this way, then you should probably use a ConcurrentMap or ConcurrentList, and use a single-thread ScheduledExecutorService, which would wake iterate through the list and remove older sessions every X minutes.
Runnable cleaner = new Runnable() {
public void run() { /* remove expired objects here */
//Using get method check whether object is expired
}
};
Executors.newScheduledThreadPool(1)
.scheduleWithFixedDelay(cleaner, 0, 30, TimeUnit.SECONDS);
Is it an option for you to use a pre-existing in-memory caching-solution instead of writing your own?
If yes you could check out Google Guava, which offers a Caching-Solution among many other things.
See: Caching with Guava
See: http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/cache/CacheBuilder.html
I agree with #quaylar (+1), use an existing caching technology, if you can.
If you can't, however, one solution is to use a java.util.Timer. Initialise it with the time till first session object expiry and put it to sleep. Then, on it awakening, have it remove your session object and reset it with the time to the next expiry time. Let java handle the timing aspects.
Well you can do something like this : I am assuming the class for your singleton object is called singleton so you have something like this (its not perfect code)
public class Singleton {
List<Objects> singletonList = Collections.synchronizedList(new ArrayList<Objects>);
}
public class RemoveExpiredItemsThread implements Runnable {
private Singleton singletonReference;
private int sleepTime = 5*60*1000;
// the constructor
// then the run method which is something like this
public void run() {
while(done == false) {
Thread.sleep(sleepTime);
singletonReference.removeItem();
}
}
}
Related
Sometimes in java I have objects that are thread unsafe and expensive to create. I would like to create a cache of those objects so I don't need to re-create them but it must also prevent concurrent access to the same object.
For example I might have DateFormat and creating it is too expensive, but I can't share a single DateFormat. For arguments sake assume that I can't use a thread safe DateFormat.
What would be fantastic is to be able to create some cache like this:
Cache<DateFormat> cache = new Cache(() -> dateFormatCreator());
// and now make use of a dateFormat that might be created for this call
// or it might be an existing one from the cache.
cache.withExclusiveAccessToObject(dateFormat -> {
// use the dateFormat here, it is not in use by any other thread at the same time.
// new dateFormats can be created on the fly as needed.
});
I should have also mentioned that ThreadLocal is not ideal as I can not ensure threads are going to be re-used.
I believe there are two paths you can go:
Option 1
Maintain an object-per-thread
This can work if you access the expensive object from a limited well defined set of threads (read, using a thread-pool and not creating threads every time, which is what happens anyway in many applications).
In this case you can use a ThreadLocal. Since within one thread everything is expected to be sequential, you can keep thread-unsafe objects in a thread local.
You can think of ThreadLocal as a map that per thread maintains a dedicated instance of an expensive object.
Option 2
Share one (or N in general) objects between M threads so that N < M. In this case there might be a situation where two threads will try to work with the same object.
I'm not aware of ready solution for this, after all its your objects that you want to maintain, but in general its pretty easy to wrap your own implementation that will provide some sort of locking/synchronized access to the objects for your types of objects.
The range of ideas for implementations can vary. As an idea: You can wrap an actual object with a runtime/build-time generated proxy making it effectively thread safe:
public interface IMyObject {
void inc();
void dec();
}
// this is an object that you would like to make thread safe
public class MyActualObject implements IMyObject {
private int counter = 0;
void inc() {counter++;}
void dec() {counter--;}
}
public class MyThreadSafeProxy implements IMyObject {
private IMyObject realObject;
public MyThreadSafeProxy(IMyObject realObject) {
this.realObject = realObject;
}
#Override
public synchronized void inc() {
realObject.inc();
}
#Override
public syncrhonized void dec() {
realObject.dec();
}
}
Instead of storing MyObject-s you can wrap them in MyThreadSafeProxy
Its possible also to generate such a proxy automatically: See cglib framework or Dynamic Proxies (java.lang.Proxy class)
From my experience usually Option 1 is preferable unless the objects you work with are too expensive so that if there are N threads in the pool, you can't really support N objects in memory.
Currently as far as I'm aware, you don't need to use any destroy methods after using IMap#tryLock unlike ILock.
Would it be a good or bad practice to change all ILocks retrieved from HazelcastInstance to IMaps and use code similar to what shown below?
public final T execute(){
try{
imapForLocking.tryLock(nonexistentInMapStringKey);
return executeCodeUnrelatedToMap();
}finally{
imapForLocking.unlock(nonexistentInMapStringKey);
}
}
Found my answer here https://groups.google.com/forum/#!topic/hazelcast/9YFGh3xwe8I
It is encouraged by hazelcast developers to use IMap for locking instead of ILock
Yes you have to call destroy as all ILock objects are kept in memory.
You can also use a distributed map for your locks:
IMap mapLocks = hazelcastInstance.getMap("mylocks");
mapLocks.lock(theKey);
when you call mapLocks.unlock(theKey), your lock is
auto-garbage-collected. This is simpler, faster and cleaner.
Why do you think you don't need any destroy method?
Probably you should always keep the lock/try/finally/unlock pattern since eventually the lock might need to timeout before being released.
iMap.lock("foo");
try {
// do something else
} finally {
iMap.unlock("foo");
}
But actually if you have the feeling you need to lock the map to do some changes you might want to look forward to use EntryProcessor which will run on the key owner and provides you with an implicit lock, so you don't actually need real locking but have the same behavior.
Locking itself is always a costly and non preferable operation.
Suppose I want to make a method non-blocking, and make the app continue as it is and still surely get the return value:
Key key = datastore.put(complexInstance);
String name = key.getName();
doSomethingWithTheName(name);
Or simply, for some Java environment that can't run thread for more than 30 seconds.
Where in the put method:
public Key put(Object instance){
Key result = null;
// In here process could take up time, say 30 seconds or more, IDK :-/
return result;
}
What is the strategy to achieve this?
You could use an implementation of an ExecutorService in combination with a Future object (http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html). You would simply start a new thread (or use an existing one) and could fetch the result later.
Java 8 made the process a lot simpler:
//field in a manager class
ScheduledExecutorService es = Executors.newScheduledThreadPool(10);
//Schedule a task
es.schedule(() -> { /* contents of a runnable */ }, 0, TimeUnit.SECONDS);
Otherwise, you can still just use an anonymous runnable with the Scheduler:
es.schedule(new Runnable() {
public void run() {
/* do what you need */
}
}, 0, TimeUnit.SECONDS);
However, as you specified, you will still need to do something for a returned value. There isn't really much that you can do, aside from use something from either a state manager, or to execute relevant methods within your runnable.
Your class needs to take a thread pool, probably via the interface ExecutorService, that the methods will run on. You could make it a private static variable, but more likely it's better for it to be passed in or at least configured by the client code, who will set size, etc.
Note that if IO is the asynchronous part, it's better to use something built on Java's nio framework than to use lots of threads.
You will need to return a Future of some sort. Through Java 7 at least (I'm not sure about 8), Java's future library is very weak and omits some obviously needed functionality. Look at either Functional Java or Google's library. But you will notice that many libraries (Apache's MINA, Amazon Web Service's Java SDK, etc.) implement their own promise libraries to get over these weaknesses. (I did the same in my company's code base. Whoops.)
I am working on an assignment and have to create two classes, one represents a person, and the other representing a bridge. Only one person can be "crossing" the bridge at any one time, but there could be people waiting to cross
I easily implemented this with multi-threading allowing for multiple people to cross at once, but I am having issues when changing it to allow only one thread to run...
My main problem is the class design they want, I have to begin the threads within the person class, but the bridge class needs to be able to wait and notify them to start/stop
Any ideas how I can do this?
You probably want to read up on wait and notify. There are tutorials with a google search.
But after you understand them a bit, you want to have the person objects call wait. Then you want the bridge object to call notify. When a person object returns from wait, it is their turn to cross (as I understand your problem.) When the person crosses, the bridge object would call notify again.
Make sure you synchronize correctly. The tutorials should help.
Read this question as well: How to use wait and notify in Java?
Lock an object like this:
// Bridge.java
public class Bridge {
private Object _mutex = new Object();
public void cross(Person p)
synchronized(_mutex) {
// code goes here
}
}
}
That is one, probably the easiest, method..
EDIT:
even easier:
public class Bridge {
public synchronized void cross(Person p)
{
// code goes here
}
}
I believe what the assignment is asking you to do is to use (or implement) a mutex for access to the shared resource, aka the bridge. http://en.wikipedia.org/wiki/Mutex
Try java.util.concurrent:
http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html#newSingleThreadExecutor%28%29
This class wil produce an ExecutorService, where you can submit yout "Persons". And the Jobes are queued, one Person will cross at time.
in trying to improve my understanding on concurrency issues, I am looking at the following scenario (Edit: I've changed the example from List to Runtime, which is closer to what I am trying):
public class Example {
private final Object lock = new Object();
private final Runtime runtime = Runtime.getRuntime();
public void add(Object o) {
synchronized (lock) { runtime.exec(program + " -add "+o); }
}
public Object[] getAll() {
synchronized (lock) { return runtime.exec(program + " -list "); }
}
public void remove(Object o) {
synchronized (lock) { runtime.exec(program + " -remove "+o); }
}
}
As it stands, each method is by thread safe when used standalone. Now, what I'm trying to figure out is how to handle where the calling class wishes to call:
for (Object o : example.getAll()) {
// problems if multiple threads perform this operation concurrently
example.remove(b);
}
But as noted, there is no guarantee that the state will be consistent between the call to getAll() and the calls to remove(). If multiple threads call this, I'll be in trouble. So my question is - How should I enable the developer to perform the operation in a thread safe manner? Ideally I wish to enforce the thread safety in a way that makes it difficult for the developer to avoid/miss, but at the same time not complicated to achieve. I can think of three options so far:
A: Make the lock 'this', so the synchronization object is accessible to calling code, which can then wrap the code blocks. Drawback: Hard to enforce at compile time:
synchronized (example) {
for (Object o : example.getAll()) {
example.remove(b);
}
}
B: Place the combined code into the Example class - and benefit from being able to optimize the implementation, as in this case. Drawback: Pain to add extensions, and potential mixing unrelated logic:
public class Example {
...
public void removeAll() {
synchronized (lock) { Runtime.exec(program + " -clear"); }
}
}
C: Provide a Closure class. Drawback: Excess code, potentially too generous of a synchronization block, could in fact make deadlocks easier:
public interface ExampleClosure {
public void execute(Example example);
}
public Class Example {
...
public void execute(ExampleClosure closure) {
synchronized (this) { closure.execute(this); }
}
}
example.execute(new ExampleClosure() {
public void execute(Example example) {
for (Object o : example.getAll()) {
example.remove(b);
}
}
}
);
Is there something I'm missing? How should synchronization be scoped to ensure the code is thread safe?
Use a ReentrantReadWriteLock which is exposed via the API. That way, if someone needs to synchronize several API calls, they can acquire a lock outside of the method calls.
In general, this is a classic multithreaded design issue. By synchronizing the data structure rather than synchronizing concepts that use the data structure, it's hard to avoid the fact that you essentially have a reference to the data structure without a lock.
I would recommend that locks not be done so close to the data structure. But it's a popular option.
A potential technique to make this style work is to use an editing tree-walker. Essentially, you expose a function that does a callback on each element.
// pointer to function:
// - takes Object by reference and can be safely altered
// - if returns true, Object will be removed from list
typedef bool (*callback_function)(Object *o);
public void editAll(callback_function func) {
synchronized (lock) {
for each element o { if (callback_function(o)) {remove o} } }
}
So then your loop becomes:
bool my_function(Object *o) {
...
if (some condition) return true;
}
...
editAll(my_function);
...
The company I work for (corensic) has test cases extracted from real bugs to verify that Jinx is finding the concurrency errors properly. This type of low level data structure locking without higher level synchronization is pretty common pattern. The tree editing callback seems to be a popular fix for this race condition.
I think everyone is missing his real problem. When iterating over the new array of Object's and trying to remove one at a time the problem is still technically unsafe (though ArrayList implantation would not explode, it just wouldnt have expected results).
Even with CopyOnWriteArrayList there is the possibility that there is an out of date read on the current list to when you are trying to remove.
The two suggestions you offered are fine (A and B). My general suggestion is B. Making a collection thread-safe is very difficult. A good way to do it is to give the client as little functionality as possible (within reason). So offering the removeAll method and removing the getAll method would suffice.
Now you can at the same time say, 'well I want to keep the API the way it is and let the client worry about additional thread-safety'. If thats the case, document thread-safety. Document the fact that a 'lookup and modify' action is both non atomic and non thread-safe.
Today's concurrent list implementations are all thread safe for the single functions that are offered (get, remove add are all thread safe). Compound functions are not though and the best that could be done is documenting how to make them thread safe.
I think j.u.c.CopyOnWriteArrayList is a good example of similar problem you're trying to solve.
JDK had a similar problem with Lists - there were various ways to synchronize on arbitrary methods, but no synchronization on multiple invocations (and that's understandable).
So CopyOnWriteArrayList actually implements the same interface but has a very special contract, and whoever calls it, is aware of it.
Similar with your solution - you should probably implement List (or whatever interface this is) and at the same time define special contracts for existing/new methods. For example, getAll's consistency is not guaranteed, and calls to .remove do not fail if o is null, or isn't inside the list, etc. If users want both combined and safe/consistent options - this class of yours would provide a special method that does exactly that (e.g. safeDeleteAll), leaving other methods close to original contract as possible.
So to answer your question - I would pick option B, but would also implement interface your original object is implementing.
From the Javadoc for List.toArray():
The returned array will be "safe" in
that no references to it are
maintained by this list. (In other
words, this method must allocate a new
array even if this list is backed by
an array). The caller is thus free to
modify the returned array.
Maybe I don't understand what you're trying to accomplish. Do you want the Object[] array to always be in-sync with the current state of the List? In order to achieve that, I think you would have to synchronize on the Example instance itself and hold the lock until your thread is done with its method call AND any Object[] array it is currently using. Otherwise, how will you ever know if the original List has been modified by another thread?
You have to use the appropriate granularity when you choose what to lock. What you're complaining about in your example is too low a level of granularity, where the lock doesn't cover all the methods that have to happen together. You need to make methods that combine all the actions that need to happen together within the same lock.
Locks are reentrant so the high-level method can call low-level synchronized methods without a problem.