5

Java supposed not to have memory leaks but it's still possible. When my program has memory leak I can fix it (I hope). But when some third party packages have it what can I do? Practically nothing except don't using this package.

Is there another solution? I like idea of sandbox. You are allowed to do whatever you want within some area and you "physical" don't have ability to bother other outside of your box. Is there way to create such sandbox for memory usage in Java? Imagine = create sandbox for memory usage, allow some package do whatever it does, take results and delete this sandbox with whatever garbage was left here! No complications with GC, no cleaning or disposition of memory. Just delete and forget about it.

Is there way to do so?

Alex
  • 171
  • 1
  • 8

1 Answers1

1

The best way is to launch another JVM, communicate with it with socket(for example), and kill the JVM after it's done.

It'll be interesting to discuss whether we can sandbox it within the same JVM.

After you are done with using the 3rd party library, and you are no longer referencing any objects from that library, what could be the garbage that's still lingering?

  1. Their classes - even though you are not referening any of them, if they are loaded by the same classloader as your code, these classes will persist. And their static fields could reference more lingering data, and so forth

  2. ThreadLocal - it could have set some thread local variables, and not cleaned them up

  3. Thread - it could have spawned some threads that persist

  4. In some global place - e.g. System.setProperty() - it'll stay there.

So in general, it's probably difficult.

However, we can use a separate classloader and a separate thread to execute the 3rd party library, and this strategy can probably unload all garbages created by the 3rd party, in most cases.

Are there existing tools for doing that? I'm not too knowledgeable about that. I do have some experience with implementing a hot reloadable server, and I have some utility classes that can be used for this purpose. For example

// wrap 3rd party code, expose it as some java.*.* interface
public class MyWrapper implements Callable<String>
{
    @Override 
    public String call()
    {
        return ThirdParty.query(..);
    }
}



HotReloader hot = new HotReloader();
Callable<String> func = (Callable<String>)hot.getAppInstance("pkg.MyWrapper");
String result = func.call();
// then dereference `hot` and `func`

see HotReloader

ZhongYu
  • 19,446
  • 5
  • 33
  • 61
  • That's good idea but a little expensive. Can you imagine to start new JVM for each database request? I was once on JavaOne conference on the presentation of Plumbr "I bet you have memory leak" and couple of their examples were about memory leak in standard database drivers. It was MySql if I'm not mistaken. – Izold Tytykalo May 14 '15 at 01:05
  • You could use ClassLoaders to isolate the problem classes. Then to cleanup any memory used by the library you just remove all references to it's classes and the loader. You could also use a separate ThreadGroup to isolate the libraries Threads, allowing you to kill them off easily. – Smith_61 May 14 '15 at 01:05
  • @IzoldTytykalo - you could use one JVM for 2 database requests :) or more. – ZhongYu May 14 '15 at 01:08
  • @Smith_61 - yes, that likely works in most cases. but it's not 100% proof. – ZhongYu May 14 '15 at 01:10
  • @bayou.io That is true. Would work in most cases that I can think of, but without knowing the type of library it's hard to come up with a perfect solution. – Smith_61 May 14 '15 at 01:11
  • @bayou.io - good thinking. Databases were just example. But if such mechanism could exist (taking care of all complications) then it would be great. Not manual playing with ClassLoader, Threads, etc. Something simple in syntax (ideally like try/catch block or transaction) which could, at least, try to kill all used memory. – Izold Tytykalo May 14 '15 at 01:19
  • @IzoldTytykalo - that would be cool. however, memory management is probably the biggest task for a JVM; creating two regions of memory in one JVM is probably not too far from creating two JVMs... – ZhongYu May 14 '15 at 01:32