We Keep Coding

Is there a way to receive object, without having reference to it?

Suppose following code:
Object obj = new Object();
obj = null;
At this point, i don't have any reference to this object, but it's still on the heap, because garbage collection don't happens instantly. Is there a way to re obtain reference on this object, before it'll be collected by GC?
Only possible way that i seen so far is to use Unsafe, which provides direct memory access, but i will need to know where in memory exactly object is allocated. Also, there is Weak\SoftReference, but they are implemented by special GC behavior.
P.S. To predict questions like "Why do you need it?" - Because science is not about why, it's about why not! (c)

This is highly JVM implementation specific. In a naive implementation having memory allocation information associated with each object, you could find an object whose memory has not been freed yet and it seems you are thinking into that direction.
However, sophisticated JVMs don’t work that way. Associating allocation information with each object would create a giant overhead, given that you may have millions of objects in your runtime. Not only regarding memory requirement, but also regarding the amount of work that has to be done for maintaining these information when allocating or freeing an object.
So what makes a part of your heap memory an object? Only the reference you are holding to it. The garbage collector traverses existing references and within the objects found this way, it will find meta information (i.e. a pointer to class specific information) needed to understand how much memory belongs to the object and how to interpret the contained data (to traverse the sub-references, if any). Everything unreferenced is unused per se and might contain old objects or might have never been used at all, who knows. Once all references to an object are gone, there is no information left about the former existence of this object.
Getting to the point, there is no explicit freeing action. When the garbage collector has found surviving objects, they will be copied to a dedicated new place and their old place is considered to be free, regardless of how many objects there were before and how much memory each individual object occupied when it was alive.
When you search memory that is considered to be unused, you may find reminiscences of old objects, but without references to their starting points, it’s impossible to say whether the bit pattern that looks like an object really is a dead object or just a coincidence. Even if you managed to resurrect an object that way, it had nothing to do with your original idea of being able to resurrect a reference, because the gc didn’t run yet.
Note that all modifications to this ordinary life time work by holding another reference to the object. E.g., when the class defines a non-trivial finalize() method, the JVM has to add a reference to the queue of objects needing finalization. Similarly, soft, weak and phantom references encapsulate a reference to the object in question. Also a debugger may keep a reference to an object, once it has seen it.
But for your trivial code Object obj = new Object(); obj = null;, assuming there’s no breakpoint set in-between, there will be no additional reference and hence, no way of resurrecting the object. A JVM may even elide the entire allocation when optimizing the code at runtime. So then you wouldn’t even find remainings of the object in the RAM when searching it as the object effectively never existed.

At this point, i don't have any reference to this object, but it's still on the heap, because garbage collection don't happens instantly.
It is undefined where it is, and it is also undefined whether or not garbage collection happens instantly.
Is there a way to re obtain reference on this object, before it'll be collected by GC?
You already had one and you threw it away. Just keep it.
I will need to know where in memory exactly object is allocated.
There is nothing in standard Java that will tell you that, and no useful way you could make use of the information if you could get it.
Also, there is Weak/SoftReference, but they are implemented by special GC behavior.
I don't see how this affects your question, whatever it is.

org.hibernate.HibernateException: Not able to obtain connection

I'm getting this exception when trying to create SQL query.
I'm trying use session in thread's run() method.
Hibernate exception org.hibernate.HibernateException: Not able to obtain connection
at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:113)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:88)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1162)
at org.hibernate.loader.Loader.doQuery(Loader.java:390)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:218)
at org.hibernate.loader.Loader.doList(Loader.java:1593)
at org.hibernate.loader.Loader.list(Loader.java:1577)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:112)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1414)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:153)

Manual memory management is not available in Java. The object will automatically become eligible to be recycled when it goes out of scope. What is holding onto your object? There must be a class, or another object referencing it for it not to be recycled by the GC.

A core concept of Java is that you have no control (which also means that you should not care) when Objects are removed from the RAM.
Generally, the Garbace-Collector will pick up an Object that is no longer referenced to by anything. WHen exactly this happens is not exactly predictable though.
So in short: You can not do that. Objects that stay in the RAM though are still referenced by something.

I would refer to this article: When does System.gc() do anything
You can actually try and call the Garbage Collector but Java is a stubborn animal and will only actually collect garbage when it feels the garbage needs to be collected.

In Java, an object will be shortlisted for garbage collection when is no longer possible to be reached from any active reference.
You can facilitate this by assigning its reference to null:
obectRef = null;
But, this is no guarantee that it will actually be deleted.

Is there any advantage to assign null to a ref when it is no longer used?

I heard that assign a reference to null explicit will help gc to collect it.
Is that true?
If an object is out of scope, will it get gc quickly?

if an object is out of scope, will it get gc quickly?
That is impossible to answer in general. However, if a reference is about to go out of scope, setting it to null just before it does will almost certainly achieve nothing.
On the other hand, if the reference variable is long-lived, then setting it to null may be useful if the referenced object is no longer needed.

Typically the JVM will do garbage collection when it needs to, so assigning a reference to null will not help it happen more quickly.

If you have an array or reference which you intend to keep it can be worth nulling it out.
If you have a long method with a large object which will not go out of scope immediately, refers to a large object it could be worth nulling it out. However in this situation, it is better the break up the method at the point where the object is no longer needed so it goes out of scope.

If that is the only reference then the GC can free the space on the heap that the object was using. However, if there is another reference to the same object then setting the first reference to null will do nothing. The second reference will still keep the object alive - so the GC will not free the space.

In general, if the reference is about to go out of scope, you don't need to explicitly null it as it will be gone soon any way.
The only explicit nulling or removing of references I consciously use are:
Closing a resource associated with an object that has a longer lifetime than that resource. For example: a java.sql.Connection implementation usually has an associated physical connection (eg a Socket): when the java.sql.Connection is closed you can null this physical connection as you are no longer using it, while the actual java.sql.Connection will (might) still be held by the user for an indefinite time. (I use this example as I am a developer of a JDBC driver, in general this example does not occur for a Java developer, but similar situations exist)
Processing relatively large 'throw-away' objects in a list or array structure. For example: the JavaMail library provides methods to get messages; these return an array of messages. If you process the messages sequentially (and then no longer need them), nulling the array-entry after processing could reduce the memory footprint of your application (with IMAP it can 'on demand' load information from the server and store it in the message, increasing its size due to processing).
There are probably some other cases I will explicitly null a reference, but that is usually to signify the unavailability of something not out of concern about garbage collection or memory usage.
However as always: don't just null because you think it could help: null if you know it will help (so profile the code, measure memory usage etc). And if it is a one off hobby application or university assignment: don't bother.

Is there a practical use for weak references? [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Weak references - how useful are they?
Since weak references can be claimed by the garbage collector at any time, is there any practical reason for using them?

If you want to keep a reference to something as long as it is used elsewhere e.g. a Listener, you can use a weak reference.
WeakHashMap can be used as a short lived cache of keys to derived data. It can also be used to keep information about objects used else where and you don't know when those objects are discarded.
BTW Soft References are like Weak references, but they will not always be cleaned up immediately. The GC will always discard weak references when it can and retain Soft References when it can.
There is another kind of reference called a Phantom Reference. This is used in the GC clean up process and refers to an object which isn't accessible to "normal" code because its in the process of being cleaned up.

Since weak reference can be claimed by garbage collector at any time, is there any practical reason to use it?
Of course there are practical reasons to use it. It would be awfully strange if the framework designers went to the enormous expense of building a weak reference system that was impractical, don't you think?
I think the question you intended to ask was:
What are realistic situations in which people use weak references?
There are many. A common one is to achieve a performance goal. When performance tuning an application one often must make a tradeoff between more memory usage and more time usage. Suppose for example there is a complex calculation that you must perform many times, but the computation is "pure" -- the answer depends only on the arguments, not upon exogenous state. You can build a cache -- a map from the arguments to the result -- but that then uses memory. You might never ask the question again, and that memory is would then be wasted.
Weak references possibly solve this problem; the cache can get quite large, and therefore time is saved if the same question is asked many times. But if the cache gets large enough that the garbage collector needs to reclaim space, it can do so safely.
The downside is of course that the cleanup policy of the garbage collector is tuned to meet the goals of the whole system, not your specific cache problem. If the GC policy and your desired cache policy are sufficiently aligned then weak references are a highly pragmatic solution to this problem.

If a WeakReference is the only reference to an object, and you want the object to hang around, you should probably be using a SoftReference instead.
WeakReferences are best used in cases where there will be other references to the object, but you can't (or don't want to have to) detect when those other references are no longer used. Then, the other reference will prevent the object from being garbage collected, and the WeakReference will just be another way of getting to the same object.
Two common use cases are:
For holding additional (often expensively calculated but reproducible) information about specific objects that you cannot modify directly, and whose lifecycle you have little control over. WeakHashMap is a perfect way of holding these references: the key in the WeakHashMap is only weakly held, and so when the key is garbage collected, the value can be removed from the Map too, and hence be garbage collected.
For implementing some kind of eventing or notification system, where "listeners" are registered with some kind of coordinator, so they can be informed when something occurs – but where you don't want to prevent these listeners from being garbage collected when they come to the end of their life. A WeakReference will point to the object while it is still alive, but point to "null" once the original object has been garbage collected.

We use it for that reason - in our example, we have a variety of listeners that must register with a service. The service keeps weak references to the listeners, while the instantiated classes keep strong references. If the classes at any time get GC'ed, the weak reference is all that remains of the listeners, which will then be GC'ed as well. It makes keeping track of the intermediary classes much easier.

The most common usage of weak references is for values in "lookup" Maps.
With normal (hard) value references, if the value in the map no longer has references to it elsewhere, you often don't need the lookup any more. With weakly referenced map values, once there are no other references to it, the object becomes a candidate for garbage collection
The fact that the map itself has a (the only) reference to the object does not stop it from being garbage collected because the reference is a weak reference

To prevent memory leaks, see this article for details.

A weak reference is a reference that does not protect the referent object from collection by a garbage collector.
An object referenced only by weak references is considered
unreachable (or "weakly reachable") and so may be collected at any
time.
Weak references are used to avoid keeping memory referenced by
unneeded objects. Some garbage-collected languages feature or support
various levels of weak references, such as Java, C#, Python, Perl, PHP or
Lisp.
Garbage collection is used to reduce the potential for memory leaks
and data corruption. There are two main types of garbage collection:
tracing and reference counting. Reference counting schemes record the
number of references to a given object and collect the object when
the reference count becomes zero. Reference-counting cannot collect
cyclic (or circular) references because only one object may be
collected at a time. Groups of mutually referencing objects which are
not directly referenced by other objects and are unreachable can thus
become permanently resident; if an application continually generates
such unreachable groups of unreachable objects this will have the
effect of a memory leak. Weak references may be used to solve the
problem of circular references if the reference cycles are avoided by
using weak references for some of the references within the group.
Weak references are also used to minimize the number of unnecessary
objects in memory by allowing the program to indicate which objects
are not critical by only weakly referencing them.

I use it generally for some type of cache. Recently accessed items are available immediately and in the case of cache miss you reload the item (DB, FS, whatever).

I use WeakSet to encode links in a graph. If a node is deleted, the links automatically disappear.

What is Object Pooling in Java?

What is object pooling and what is a weak object reference ?
How can we implement them using Java?

An object pool is a collection of a particular object that an application will create and keep on hand for those situations where creating each instance is expensive. A good example would be a database connection or a worker thread. The pool checks instances in and out for users like books out of a library.
Usually object pooling is handled by a Java EE application server. If you need to do it yourself, best to use something like Apache's object pool. Don't write one yourself; thread safety and other issues can make it complicated.
Here's a good reference on weak object references.

Check common-pools
provides an Object-pooling API
It is generally used for objects whose creation is expensive. In order to avoid that you maintain a pool of N pre-created objects and reuse them.

A weak reference is a kind of reference variable which is treated specially by the garbage collector.
This introduces another kind of reachability, any object may be:
strongly reachable (reachable from any life thread by only normal references)
weakly reachable (not strong reachable, but reachable by a weak reference (or by multiple ways, which each include a weak reference))
not reachable at all
(There are also Soft References and Phantom References, which I leave out here - they work similarly and introduce more levels between.)
If an object is not reachable at all, it can be garbage-collected at any time.
If an object is strongly reachable, it can not be garbage-collected at all.
If the garbage collector finds that an object (or a group of objects) is weakly reachable (maybe by multiple weak references), it clears all these references at once, and then the objects are not reachable (and can be garbage-collected).
(Actually there is/may be a finalization step between the "non reachable" and the collection, which also may make the object again reachable.)
For using Weak references, you can use the class java.lang.ref.WeakReference - the actual reference is in a private variable of this class, and can only be set with the constructor, and later cleared. You can subclass this class, if you need other data apart from the reference itself, which should still be there when the reference is cleared.
For an object pool in the sense of "avoid costly instantiation", a weak reference is not the right tool.

An object pool is any collection of object which are recycled, rather than recreated each time they are needed.
There are a number of ways you can implement such an Object Pool depending on your requirements. Object pools used to help performance even for simple objects but are not as useful in Java 5+.
I suggest you only use them for objects which connection to external resources such as file, sockets or database connections.

The idea of object pool pattern is similar to that of library. Everyone of us know it is cheaper and easier to go to a library and borrow a book instead of buying it.Likewise, it is cheaper (with regards to system memory and speed) for a process to borrow an object rather then to instantiate it. So such process in which a process borrow an object from another process is termed as object pooling.

Pooling & Object Pooling:
Pooling basically means utilizing the resources efficiently, by limiting access of the objects to only the period the client requires it.
Increasing utilization through pooling usually increases system performance.
Object pooling is a way to manage access to a finite set of objects among competing clients.
In other words, object pooling is nothing but sharing of objects between different clients.
Since object pooling allows sharing of objects, the other clients/processes need not re-instantiate the object (which decreases the load time), instead they can use an existing object.
After the usage, the objects are returned to the pool.
Weak reference object:
A weak reference is a holder for a reference to an object called the referent.
With weak references, you can maintain a reference to the referent without preventing it from being garbage collected.
When the garbage collector traces the heap, if the only outstanding references to an object are weak references, the referent becomes a candidate for GC as if there were no outstanding references and any outstanding weak references are cleared.
Remember, GC always, using some algorithms, reclaim the weakly reachable objects.

I implemented a simple ObjectPool in Java, see here
It doesn't use weak object reference though. Purpose of weak object reference to allow collect an object memory even if there are references to the object, but they are weak. It is more useful for caches than for object pools, although can be used for them too.

I suspect you are trying to ask about a SoftReference cache (not WeakReference). I cannot find it right now, but I remember reading from someone who implemented a proprietary JVM begging people to not use them. His argument was that these caches suppose that the author of the garbage collector somehow knows more about your caching needs than you do (which should never be true).
What I recall seeing back in the day was that if a GC cycle did not free up enough memory, all SoftReferences subsequently got cleared at once, i.e. the cache goes from ridiculously (out of memory) full to (an equally ridiculous) totally empty. Instead, choose a cache implementation that works based on size, or age, or both, i.e. one that you can give your own sensible rules to, rather than trying to offload the decision of how your cache works to the person who wrote the garbage collector for some reason.