garbage-collection

问题 UPD 21.11.2017: the bug is fixed in JDK, see comment from Vicente Romero Summary: If for statement is used for any Iterable implementation the collection will remain in the heap memory till the end of current scope (method, statement body) and won't be garbage collected even if you don't have any other references to the collection and the application needs to allocate a new memory. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8175883 https://bugs.openjdk.java.net/browse/JDK-8175883

问题 is there a way to check if an object can be fetched by the garbage collector? Somewhere in my code I've got a reference to an object: MyObject mo = myObject; Then, via Eclipse Debugger, I get the objects memory location. Afterwards, I set the reference null: mo = null; Is there any way to check if the previously referenced object is now suitable for garbage collection or if there's somewhere another reference to it? Thanks a lot, Stefan 回答1: You cannot do this at runtime with an arbitrary

问题 I use the following method in a piece of production code: private void DownloadData(Uri uri) { WebClient webClient = new WebClient(); DownloadDataCompletedEventHandler eh = null; eh = delegate(object sender, DownloadDataCompletedEventArgs e) { webClient.DownloadDataCompleted -= eh; ((IDisposable) webClient).Dispose(); OnDataDownloaded(); }; webClient.DownloadDataCompleted += eh; webClient.DownloadDataAsync(uri); } I am now worried that a hard to reproduce bug might be caused by the WebClient

问题 I'm currently working on a website that makes large use of cached data to avoid roundtrips. At startup we get a "large" graph (hundreds of thouthands of different kinds of objects). Those objects are retrieved over WCF and deserialized (we use protocol buffers for serialization) I'm using redgate's memory profiler to debug memory issues (the memory didn't seem to fit with how much memory we should need "after" we're done initializing and end up with this report Now what we can gather from

问题 I'm reading on JVM tuning, and it occurred to me that the JVM keeps moving objects around when it does GC. But Java Objects have references to each other, which one would presume are implemented as pointers, but the JVM can't possibly go over the whole heap after every time it moved objects around, and update all the references; surely that would take for ever. So how does it resolve references, if the references do not change, but the physical location of the objects do? I've read a lot

问题 In this code example, the ExecutorService is used one and allowed to go out of scope. public static void main(String[] args) { ExecutorService executorService = Executors.newFixedThreadPool(3); executorService.submit(new Runnable() { public void run() { System.out.println("hello"); } }); } Once executorService is out of scope, it should get collected and finalized. The finalize() method in ThreadPoolExecutor calls shutdown(). /** * Invokes {@code shutdown} when this executor is no longer *

问题 I am running a Java program with the G1 garbage collector using the following options: -XX:-UseBiasedLocking -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/var/tmp/gclog.out The output looks like this... 44900.297: [GC pause (young)44900.386 (initial-mark), 0.08894851 secs] : [GC concurrent-mark-start] [Parallel Time: 83.7 ms] [GC Worker Start Time (ms): 44900297.6 44900297.6 44900297.6 44900297.6 44900297.6 44900297.7 44900297.7

问题 I built a http.Client for HTTP2 connection, what do I need to do to release the client and resource used? Thanks. 回答1: http.Client does not require any special way to free "used" resources. When it becomes unreachable, memory used by it will be reclaimed by the garbage collector. http.Client does not store connection or state information. The documentation even states that http.Client should be reused: The Client's Transport typically has internal state (cached TCP connections), so Clients

问题 I'm playing around with C++/CLI, using the MSDN documentation and the ECMA standard, and Visual C++ Express 2010. What struck me was the following departure from C++: For ref classes, both the finalizer and destructor must be written so they can be executed multiple times and on objects that have not been fully constructed. I concocted a little example: #include <iostream> ref struct Foo { Foo() { std::wcout << L"Foo()\n"; } ~Foo() { std::wcout << L"~Foo()\n"; this->!Foo(); } !Foo() { std:

问题 I'm playing around with C++/CLI, using the MSDN documentation and the ECMA standard, and Visual C++ Express 2010. What struck me was the following departure from C++: For ref classes, both the finalizer and destructor must be written so they can be executed multiple times and on objects that have not been fully constructed. I concocted a little example: #include <iostream> ref struct Foo { Foo() { std::wcout << L"Foo()\n"; } ~Foo() { std::wcout << L"~Foo()\n"; this->!Foo(); } !Foo() { std: