截至頻率

隨著2013年即將結束，我最近發現了幾篇與我認為“核心Java”知識有關的帖子。 這篇文章列出了三個帖子，并提供了一個簡短說明的論壇。 我這樣做有兩個目的：（1）幫助其他人意識到這些優秀職位的存在；（2）當我想再次找到這些職位時，充當自己的榮耀“書簽”。 這些帖子和論壇足以證明我花點時間將它們以PDF格式“ 打印 ”（保存）到我的硬盤中。

熱點JVM標志

Kirk Pepperdine的“ JVM HotSpot標志案例研究 ”是有關HotSpot JVM標志的實用分析和應用的極佳資源。 Pepperdine演示了使用-XX：+ PrintFlagsFinal標志（我也已在其上進行博客 ）以“通過弄清楚默認設置是什么來識別冗余標志”，以便他可以刪除不推薦使用的標志和簡單地顯式設置為無論如何他們都會有默認值。 然后，Pepperdine分析在刪除不贊成使用的標志和刪除僅重新設置默認值的標志之后剩余的一些標志。 他分析了它們之間的相互作用，有時甚至相互取代。 Pepperdine的結論段落明確表達了以下建議：

我認為擁有如此可配置，如此靈活的技術真是太棒了。 但是這種靈活性是一把雙刃劍，不應盲目地使用所有這些可配置性。 我確實知道一件事，即您的應用程序性能確實取決于其配置方式。 弄亂一個標志可能會對應用程序的性能產生不利影響，弄錯了要比弄好它容易得多。 而且很多時候，JVM確實可以立即使用它。

遠程Java調試

亞當·比恩 （ Adam Bien ）的文章“ 遠程調試的選項是什么 ……”簡要回顧了可用于調試 遠程Java進程 （如應用程序服務器）的關鍵選項 。 在本文中，他引用了連接和調用詳細信息以獲取更多詳細信息，但提供了可用傳輸的簡要摘要（ dt_shmem用于Socket 和 Windows共享內存訪問的dt_socket和dt_shmem ）， suspend=y 與 suspend = n和server=y 與 server=n 。

Java標準庫/語言愿望清單

問題“ Java標準庫迫切需要什么功能？ 最近在Reddit上被問到。 由于各種原因，我發現答復（到目前為止有72篇）很有趣。 在在線論壇中，注釋作者已經舉了幾個例子，他們以犧牲他人的身份來展示自己的高級知識，這在在線論壇上已經變得越來越普遍，但是大多數注釋都很有見地，并且為Java開發人員希望添加到該語言中提供了有趣的視角。 （在少數情況下）或SDK（在答復中更為常見，可能是因為與問題更緊密地吻合）。 答案包括番石榴的所有子集， Apache Commons的全部或子集，不贊成使用和刪除大量未使用的功能和庫，以及屬性注釋或其他用于替換獲取/設置方法（或Project Lombok ）的機制。

我認為Tillerino發表了有見地的評論 ，一些Java開發人員可能對Apache Commons（特別是Lang）和Guava之類的“公共”庫沒有意識到。 蒂勒里諾說：

每個定義的commons-lang提供了Java API中沒有的那些類。 commons-lang提供的功能出現在Java API中然后從commons-lang中刪除是很常見的。 我使用了其他兩個程序包，盡管commons-lang可能是所有項目的90％的一部分，但其他程序僅僅是專門成為Java API一部分的方式。 對于Java開發人員來說，知道哪些功能可以通過公用區輕松訪問很重要，但是我認為這條線已經很清楚了。

Java SE采用和標準化流行庫功能的最新示例包括Java 7添加了Objects類和Java 8添加了Optional類，這兩個類均與Guava的Objects類和Optional類等類具有明顯的相似性。 我們在Java EE世界中也看到了這一點，其中最主要的例子之一就是近年來受Spring Framework啟發的Java EE的許多新功能。

這是我在《 標準化工作：開源的危險關系》一書中寫的一個普遍原則。 我們的開發人員應該對此原則感到“滿意”，因為開源似乎可以幫助完善最好的想法，一旦這些功能的流行性和實用性得到證明，組織可以將緩慢發展的標準納入標準。 這些開源產品的實現使我們能夠在標準實現中使用該功能。

我感謝Nikita Salnikov-Tarnovski最近發布的RMI要求Full GC每小時運行一次 ，原因有以下三個：

他在這篇文章中談到的最終問題是我遇到的一個問題。

我同意他關于我們追尋的錯誤的開場白，“隨著時間的流逝，它們正在演變并變得更加卑鄙和丑陋。”

Salnikov-Tarnovski不僅陳述了解決該平均漏洞的方法，還描述了隔離錯誤并確定其原因的過程。

由于設置了名為sun.rmi.dgc.server.gcInterval的HotSpot RMI屬性， sun.rmi.dgc.server.gcInterval -Tarnovski遇到的問題與“每小時發生的完整GC” sun.rmi.dgc.server.gcInterval 。 在Java SE 6中，針對錯誤JDK-6200091的修復（“默認情況下RMI gcInterval太短”）將sun.rmi.dgc.server.gcInterval和sun.rmi.dgc.server.gcInterval的設置延長了一小時。 作為參考，與常規定期分布式垃圾收集相關的其他感興趣的帖子包括：我們如何解決–在Tomcat上每1分鐘進行一次 GC，為Sun Hotspots，JVM 6分析GC日志， 由于遠程方法調用（RMI）導致無法解釋的System.gc（）調用）或公開垃圾收集 ， 如果不這樣做，JBoss的運行會很慢 。

我喜歡Salnikov-Tarnovski記錄了他解決問題的步驟，而不是簡單地指出解決方案。 盡管在這種情況下，解決方案是使用Google搜索引擎搜索其他人解決該問題的方法，但是之前嘗試的幾個步驟可以向其他人說明如何縮小問題并磨練缺陷。 我在此博客上被問到的最大問題之一是，有人留下評論詢問我如何找到該帖子中記錄的修復程序。 當我發布并閱讀此評論時，我已經忘記了解決該特別棘手問題的步驟，因此實際上無濟于事。

在本文中Salnikov-Tarnovski的案例中，所提供的全部內容是“有時系統運行緩慢”（我敢肯定，我們當中很多人已經多次接受了該請求）。 診斷問題的步驟包括監視響應時間以查看常規模式，排除此類情況下的常見嫌疑人，增加日志記錄輸出并最終求助于Google。

結論

每周都有成千上萬的新職位，為軟件開發人員詳細介紹各種新技術和工具。 這些都是有價值的帖子，可以幫助我們所有人學習新事物，但是我也感謝那些關注“核心概念”的帖子和論壇。 雖然核心概念可能不像新事物那樣令人興奮或浮華，但核心概念可幫助我們更好地交付和管理軟件，以使客戶受益。

參考：在Inspired by Actual Events博客中， JCG合作伙伴 Dustin Marx 用Core Java帖子結束了2013 。

翻譯自: https://www.javacodegeeks.com/2014/01/closing-2013-with-core-java-posts.html

截至頻率

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的截至频率_截至2013年核心Java帖子的全部內容，希望文章能夠幫你解決所遇到的問題。

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