1

Recently faced this question in an interview:

You have a java application, and it uses a connection object to connect to the different clients. The connection object is of type ClientConnection. I want to know how many live connection objects are present at a particular moment in this application?

Answer given by me:

  1. I will make a static variable connectionCount in ClientConnection class.
  2. Every time ClientConnection constructor is called, I will increment the static variable count by 1.
  3. I will override the finalize() method in ClientConnection and decrements the variable count by 1, every time it is called.

But Interviewer doesn't look satisfied by this answer.
Do we have any other approach for this question?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Amit Bhati
  • 5,569
  • 1
  • 24
  • 45
  • 2
    I wouldn't be either. If the candidate didn't immediately start discussing the Factory Pattern and resource pools in general I would not consider the candidate. Furthermore, as `finalize` is not guaranteed to be called this method would not work. And finally, if there was no mention by you of concurrency and visibility concerns then that would be a _very_ bad sign for someone suggesting a shared mutable state. – Boris the Spider Dec 27 '17 at 18:24
  • 3
    An object may be dead but not yet finalized. So your solution may return an incorrect number. – Jorn Vernee Dec 27 '17 at 18:25
  • Can you clarify what `ClientConnection` is? If it opens a socket, the socket may be kept open by the OS even after the `ClientConnection` is closed – ubadub Dec 27 '17 at 18:28
  • @Boris, He stopped me from using factory pattern, considering the fact that connection object will always be of same type ClientConnection. Resource pooling and multi-threading, yes a miss from my side. – Amit Bhati Dec 27 '17 at 18:37
  • Did the interviewer provide any details on the methods on the `ClientConnection` object such as `open()` or `close()`? Saying how many "live" connections implies that the existence of the object does not necessarily mean the connection is "live". For example with JDBC connections you can call `close()` even though the object reference may live well beyond the `close()` call – Andy Guibert Dec 27 '17 at 19:39

3 Answers3

1

I think the key part where you went wrong was making the assumption that the interviewer was literally wanting you to track the number of object instances in the JVM. Instead, I think this was meant to be keeping track of the number of objects in an "open" state, where the user of the object would need to dispose of the object via a close() method when they are done using it (similar to how a JDBC Connection works).

Assuming that ClientConnection has some sort of open and close methods, I would have implemented in the following way:

public class ClientConnection {

  private static final AtomicInteger count = new AtomicInteger();

  public void open() {
    // This could also be in the constructor, depending on
    // the requirements of the object
    count.incrementAndGet();
  }

  public void close() {
    // <close out the physical connection>
    count.decrementAndGet();
  }

  public static int getConnectionCount() {
    return count.get();
  }

}

Basically just using a thread-safe integer as a static member of the class, and then measuring the lifecycle of the connection via open/close methods. You could also consider a public constructor to act as the open method.

Andy Guibert
  • 41,446
  • 8
  • 38
  • 61
0

The finalize() method might not be called immediately when a connection is closed. It is not called until the object is garbage collected, which could be at any time, or not at all if the JVM exits without garbage collection being run. There should be some kind of listener on the connection that gets called when the connection is closed (when the socket is closed). Here is some help in solving that problem.

Ben Ingle
  • 575
  • 2
  • 12
0

Relying on finalize() is bad, because it is not guaranteed to be called within the lifetime of any given program.

Further, just because the JVM garbage collects a given object does not mean the operating system will do anything special with any resources that object requested; for example, assuming ClientConnection opens a socket, the OS might keep the socket alive even after the object has been garbage collected.

You need either a listener on the connection or you need to use the object pool pattern.

ubadub
  • 3,571
  • 21
  • 32