pnp型三极管 饱和 截至
随着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(在答复中更为常见，可能是因为与问题更紧密地吻合)。 答案包括
Guava的
所有子集，
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热点的GC日志，JVM 6
，
由于远程方法调用(RMI)导致无法解释的System.gc()调用)或公开垃圾收集
，
如果不这样做，JBoss的运行会很慢
。
我喜欢Salnikov-Tarnovski记录了他解决问题的步骤，而不是简单地指出解决方案。 尽管在这种情况下，解决方案是
使用Google搜索引擎搜索
其他人解决问题的方法，但是之前尝试的几个步骤可以向其他人说明如何缩小问题并磨练缺陷。 我在此博客上被问到的最大问题之一是，当有人留下评论询问我如何找到该帖子中记录的修复程序时。 在我发布并阅读此评论时，我已经忘记了解决该特别棘手的问题所使用的步骤，因此实际上并没有帮助。
在本文中Salnikov-Tarnovski的案例中，所提供的几乎全部是“有时系统运行缓慢”(我敢肯定，我们中的许多人已经多次接受了该系统)。 诊断问题的步骤包括监视响应时间以查看常规模式，排除此类情况下的常见嫌疑人，增加日志记录输出并最终求助于Google。
结论
每周都有成千上万的新职位，为软件开发人员详细介绍各种新技术和工具。 这些是有价值的帖子，可以帮助我们所有人学习新事物，但是我也感谢那些关注“核心概念”的帖子和论坛。 虽然核心概念可能不像新事物那样令人兴奋或浮华，但核心概念可帮助我们更好地交付和管理软件，以使客户受益。
翻译自:
https://www.javacodegeeks.com/2014/01/closing-2013-with-core-java-posts.html
pnp型三极管 饱和 截至