Resource leaks: interview questions

line 3 · Resource leak

A new scroll listener is added on every navigation and never removed. Old listeners keep running (and keep their closures alive), so each scroll does more and more work and memory grows for the whole session.

  const onScroll = () => {    const depth = (window.scrollY + window.innerHeight) / document.body.scrollHeight;    maxDepth = Math.max(maxDepth, depth);  };  window.addEventListener("scroll", onScroll, { passive: true });  return () => {    window.removeEventListener("scroll", onScroll);    sendBeacon("/analytics", { pageId, maxDepth });  };

Interview follow-up: Removing a listener requires the same function reference that was added, so name the handler.

line 2 · Resource leak

The response body is never closed. Each call leaves a connection and its file descriptor open, and they can't be returned to the pool, so the process eventually hits its open-file limit.

	resp, err := client.Get(url)	if err != nil {		return 0, err	}	defer resp.Body.Close()

Interview follow-up: Some interviewers also ask about draining the body (io.Copy(io.Discard, resp.Body)) so keep-alive connections can be reused.

line 2 · Resource leak

The connection, statement and result set are never closed, so every call keeps a pooled connection checked out. Once the pool is exhausted, new requests block until they time out.

    try (Connection conn = dataSource.getConnection();         PreparedStatement ps = conn.prepareStatement("SELECT 1 FROM users WHERE email = ?")) {        ps.setString(1, email);        try (ResultSet rs = ps.executeQuery()) {            return rs.next();        }    }

Interview follow-up: Explain why try-with-resources beats a finally block: it closes in reverse order and keeps suppressed exceptions.