stacktraces

我們公司致力于使軟件錯誤的原因對開發(fā)人員和運營透明。 與替代解決方案相反， 我們在您發(fā)現源代碼中惡意代碼的地方指出了問題的所在 。 即使目前我們以檢測內存泄漏的能力而聞名，但我們也正在擴展到其他領域。 為了給您一些有關我們研究方向的提示，我們決定通過三個示例進行分享。

這些示例歸結為JVM功能，以提供有意義的堆棧跟蹤。 在許多情況下，stacktrace確實包含解決問題所需的所有信息。 在其他情況下，它只是浮??出水面，不知道可能是什么引起了潛在的問題。 讓我用觸發(fā)以下臭名昭著的錯誤消息的三個示例進行說明：

• java.lang.OutOfMemoryError：無法創(chuàng)建新的本機線程
• java.io.IOException：系統中打開的文件過多
• java.lang.OutOfMemoryError：Java堆空間

所有示例都使用簡單的代碼片段進行了說明，從而使?jié)撛趩栴}更易于理解。

線程太多

static void createTooManyThreads() {try {for (int i = 0; i < TOO_MANY; i++) {Thread t = new Thread(new Runnable() {public void run() {try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}}});t.start();}} catch (OutOfMemoryError e) {e.printStackTrace();} }

在上面的代碼中，我們一直在啟動線程，直到達到系統限制并遇到“ java.lang.OutOfMemoryError：無法創(chuàng)建新的本機線程”消息。 理解問題與線程限制耗盡有關，這有什么問題？ 讓我們仔細看看stacktrace：

java.lang.OutOfMemoryError: unable to create new native threadat java.lang.Thread.start0(Native Method)at java.lang.Thread.start(Thread.java:693)at eu.plumbr.demo.MisleadingStacktrace.createTooManyThreads(MisleadingStacktrace.java:34)at eu.plumbr.demo.MisleadingStacktrace.main(MisleadingStacktrace.java:16)

問題就一直盯著我們的臉-有人告訴我們添加最后一根稻草將駱駝背折斷了。 同時，我們沒有一個線索是，駱駝已經被完全裝載了。 如果錯誤消息還包含一種方法，以查看在我們最后一次嘗試啟動最后一個調用導致上述堆棧跟蹤之前，哪個調用堆棧正在消耗線程的不同跟蹤，那么這將使開發(fā)人員的工作更加輕松。

但是讓我們看一下相同的問題–從另一個角度來看資源消耗：

打開的文件太多

再次，讓我們從示例代碼開始：

static void createTooManyFiles() {try {for (int i = 0; i < TOO_MANY; i++) {File f = new File(PATH_TO_FILE + i + ".txt");f.createNewFile();OutputStream s = new FileOutputStream(f);s.write(1);}} catch (IOException e) {e.printStackTrace();} }

該示例嘗試創(chuàng)建許多文件，并且僅在每個文件中寫入一個整數而不關閉前一個文件。 再次，運行上面的代碼會導致堆棧跟蹤不太有用：

java.io.IOException: Too many open files in systemat java.io.UnixFileSystem.createFileExclusively(Native Method)at java.io.File.createNewFile(File.java:947)at eu.plumbr.demo.MisleadingStacktrace.createTooManyFiles(MisleadingStacktrace.java:45)at eu.plumbr.demo.MisleadingStacktrace.main(MisleadingStacktrace.java:17)

現在，以不同的方式掩蓋了相同的問題-我們確實得到了這樣的消息：我現在嘗試過多地打開一個文件，但是-誰打開了其他文件以在無法完成運行的程度上向JVM施加壓力？

如果您仍然不確定，請看第三個示例，即我們目前的面包和黃油：

消耗太多內存

代碼示例再次很簡單–我們采用數據結構并不斷增加結構，直到可用堆耗盡為止：

static void createTooLargeDataStructure() {try {List l = new ArrayList();for (int i = 0; i < TOO_MANY; i++) {l.add(i);}} catch (OutOfMemoryError e) {e.printStackTrace();} }

運行代碼會給您帶來臭名昭著的java.lang.OutOfMemoryError：Java堆空間消息。 同樣，如果所討論的數據結構是通過源代碼中的不同可能位置填充的，則很難解釋。

我知道所有C語言開發(fā)人員現在都無奈地聳了聳肩，因為在他們的世界中，以上所有內容都只是采取段錯誤的形式，但是–如果我們走得那么遠，為什么我們不能做得更好？ 我相信我們可以做到，這就是我們要做的– 找到適合您的性能瓶頸 。

如果您對完整的代碼示例感興趣，可以在此處下載。 該代碼在JDK 7u25上的OS X 10.9的Macbook Pro上運行。 之后，請確保您不會錯過未來有趣內容的更新，并訂閱我們的Twitter feed 。

參考： Stacktraces告訴了事實。 但事實并非如此。 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2013/11/stacktraces-are-telling-the-truth-but-not-the-whole-truth.html

stacktraces

總結

以上是生活随笔為你收集整理的stacktraces_Stacktraces告诉了事实。 但事实并非如此。的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。