截至频率_截至2013年核心Java帖子

截至频率

随着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。