截止到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用于套接字和 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。