Java的那些事儿
这篇讲的是作者从个人经验出发，分享对Java语言的理解与数据库开发实战心得。作者认为，Java因其设计上的后发优势、简单的语法和强大的生态（如优秀的IDE），相比C/C++在开发效率上更胜一筹，尤其在现代注重高并发与可扩展性的项目中。 文章的重点，落在了Java开发者（特别是使用Oracle数据库时）必须掌握的三个核心数据库优化点上：首先是连接池技术，以解决连接数失控或过度复用的问题，并给出了基于Oracle UCP的配置示例；其次是语句池技术，强调必须使用绑定变量并启用语句缓存，以避免昂贵的软解析开销；最后是资源泄露问题，指出Java的内存回收机制无法处理数据库连接、游标或事务锁的泄露，这常常是异常处理不严谨导致的，并附有锁等待的监控图作为例证。 作者从实用主义出发，最终将讨论落脚于具体的技术细节与解决方案，对于从事数据库应用开发的Java程序员来说，文中列出的这几点排查清单具有直接的参考价值。
你应该更新的Java知识之构建工具
这篇文章直指现代Java开发中一个常被忽视但至关重要的环节：构建工具的演进与选择。作者从早期的Ant和Maven谈起，精准地指出了它们的痛点——Ant过于手工化，而Maven在扩展性和灵活性上存在“致命伤”，以至于项目复杂后常需回归脚本编写。 随后，文章引出了新一代构建工具Gradle和Buildr。与Maven的XML不同，它们允许使用Groovy或Ruby这类更优雅的程序设计语言来编写构建脚本，极大地提升了灵活性和表现力。其中，Gradle被着重介绍：它拥有详尽的文档、商业公司的支持，并在尚未发布1.0版本时就已获得Spring大奖及Spring官方项目转投，证明了其强大的实力和社区认可度。 文章通过一个简洁的build.gradle脚本示例，直观展示了使用Gradle进行Java项目构建的清晰与便捷。作者的观点很明确：对于今天的Java项目，Gradle因其易用性、强大的扩展能力和活跃的生态，已成为更值得拥抱的现代构建方案。
Java应用运维
这篇讲的是Java应用运维如何从零开始，一步步构建出自动化体系的过程。作者以亲身经历出发，描绘了运维工作随着应用规模增长而不断演进的典型路径。 文章首先从最基础的单机部署讲起：用Maven打包、SCP上传、执行启动脚本，再通过一个简单的JSP文件验证应用是否真正跑起来了。随着发布需求增多，脚本开始支持应用包和静态页面的快速更新与回滚。当应用从一台扩展到多台服务器时，运维工作又面临新挑战——不仅要搭建负载均衡环境，还要实现分批发布、灰度发布等策略。作者详细描述了如何通过脚本管理多台服务器，最终发展出一个包含应用信息登记、发布管理和权限控制的Web版运维系统。 这个演进过程的核心，是“用脚本解决重复劳动，用系统管理复杂度”。从最初的手工操作，到积累出环境部署、应用发布、负载均衡管理等一系列脚本，再到整合成支持多应用、多权限的运维平台，每一步都紧扣实际痛点。文章最后还提到，当运维规模继续扩大，还会遇到VLAN划分、虚拟化引入等更高级的挑战，为读者留下了进一步思考的空间。
Eclipse Xtend对Java说：我帮你瘦身
这篇文章讲的是 Eclipse 基金会推出 Xtend 语言，旨在为冗长的 Java 语法“瘦身”。作者从 Bruce Tate 在《七周七语言》中对 Java 冗余代码的生动批评切入，引出了这个与 Eclipse IDE 紧密集成的解决方案。 Xtend 的核心思路是作为 Java 的“模板语言”，它编写的代码在 IDE 中保存时会自动转译为对应的 Java 代码。文章重点展示了 Xtend 如何简化日常编码：比如通过类型推测省略显式类型声明，用 `person.name` 直接访问属性替代 `getName()` 调用，以及让 `switch` 语句支持更复杂的对象匹配。此外，它还引入了方便的多行字符串模板和强大的闭包语法，让代码更接近 Ruby 等脚本语言的简洁风格。 Xtend 的价值在于，它允许开发者在熟悉的 Java 生态和现有项目基础上，享受更高效、更富表现力的编码体验，无需完全切换到新语言。对于追求生产力又希望保持技术栈稳定的 Java 开发者而言，这是一个值得考虑的“语法增强”工具。
记录帖：碰到的一些Java问题
这是一篇来自一线开发者的实战记录帖，汇集了几个典型的Java问题排查案例。文章以问题驱动，详细复现了从现象到根因的完整思考路径。 其中令人印象深刻的是集群启动失败的案例：相同的应用包和环境，部分节点却抛出NoClassDefFoundError。作者借助btrace追踪类加载器，最终发现是因为不同Linux节点上`File.listdir`返回的文件顺序（按inode号排序）存在差异，导致两个同名但内容不同的jar中的类被加载到了不同的地方，引发了冲突。这个发现揭示了一个隐蔽而常见的Java模块加载陷阱。 此外，文章还涵盖了GC频繁但不触发OOM的调优困境、堆外内存泄露（通常与Deflater未释放有关）的定位方法、压测时因第三方线程池配置不足导致的压力瓶颈，以及因未正确处理外部进程的标准输出/错误流而引发的应用死锁。 这些案例的价值在于，它们不仅仅给出了“怎么做”，更分享了“为什么这么想”和“过程中踩到了什么坑”，比如放弃`-XX:+TraceClassLoading`的原因，或是从网卡流量、线程状态逐步缩小排查范围的思路。对于遇到类似问题的开发者，这是一份可以直接参考的排查手册。
通过JNI实现Java对C/C++的调用
这篇讲解的是如何通过JNI（Java Native Interface）这座桥梁，让Java代码能够调用底层的C/C++函数，以利用后者在性能或系统调用上的优势。 文章开门见山地指出，JNI是Java平台的一部分，旨在实现Java与其他语言的交互。其核心是一个清晰的实现流程：开发者首先编写一个包含native声明方法的Java类，并通过静态块加载对应的动态库；接着，通过javac编译Java代码，并使用javah命令生成C语言头文件，这个头文件定义了需要在本地代码中实现的方法签名；然后，按照头文件声明编写C/C++函数的具体逻辑；最后，将本地代码编译成平台相关的动态链接库（如.so或.dll文件），并在运行Java程序时通过指定库路径来加载它。 文章的亮点在于其实用性，不仅给出了从声明native方法、生成头文件到编译链接的完整命令行示例，还特别说明了如何配置运行环境。例如，在Linux下可以通过设置LD_LIBRARY_PATH环境变量或指定`java.library.path`系统属性来让Java虚拟机找到动态库，而部署时则可以将库文件直接拷贝到系统标准的库搜索路径中，从而避免重复配置。这些细节使得整个从编码到运行的链条非常清晰，适合需要进行跨语言调用的开发者参考。
HBase Java客户端编程
这篇教程从在Windows系统下用Java操作HBase的实际需求出发，基于HBase 0.90.2版本，手把手演示了在Eclipse IDE中进行客户端编程的完整流程。 文章首先清晰拆解了环境搭建步骤：除了JDK与Eclipse的安装，重点讲解了如何将HBase的jar包与集群的`hbase-site.xml`配置文件正确导入Java工程。这为后续编码打下了基础。 随后，教程提供了一套覆盖HBase核心操作的Java代码示例，包括如何初始化配置、创建/删除数据表，以及插入、删除和多种方式查询记录。每一步都配有直接可用的代码片段，例如通过`HBaseAdmin`管理表结构，使用`HTable`、`Put`、`Get`和`Scan`类进行数据读写。 对于需要在本地快速搭建环境并上手HBase Java API的开发者来说，这篇指南省去了繁琐的摸索过程，提供了从环境配置到基本CRUD操作的完整参考路径。
Java 6 JVM参数选项大全（中文版）
这篇系统梳理了Java 6 JVM所有非稳态参数选项的实用指南。作者基于SUN官方文档进行翻译，并补充了大量背景资料与原理阐释，旨在帮助开发者深入理解每个参数的含义与适用场景。 文章清晰区分了参数的使用语法（如-XX:+启用、-XX:-关闭），并详细列举了行为选项与性能选项。对于每个选项，不仅说明了默认值与平台限制，更通过关联知识点揭示了其底层逻辑。例如，在解释新生代收集担保（-XX:+HandlePromotionFailure）时，文章剖析了Minor GC的运作机制与担保策略的利弊；在介绍自旋锁优化（-XX:+UseSpinning）时，则联系了CAS与OS互斥锁的原理。 这份文档覆盖了垃圾收集器选择（如CMS、Parallel GC）、内存管理、类加载校验、线程优化及特定平台（如Solaris）设置等多个关键调优维度。对于正在进行JVM性能优化或需要精确控制运行时行为的工程师而言，它将是一份内容扎实的中文参考手册。
Java泛型简明教程
这篇教程从一个Java程序员常见的困惑出发：尽管泛型（Generics）在Java SE 5.0中引入已久，但很多开发者对其意义和最佳使用方式依然模糊。作者的目的，正是用最简洁的形式梳理泛型的核心知识。
文章开篇即点明，泛型的核心价值在于它作为一种“便捷语法”，能显著减少繁琐的类型转换（Casting）操作。通过对比有无泛型的代码示例——从需要手动转型的 `List` 到直接返回特定类型的 `List
Java heap dump触发和分析
这篇文章聚焦Java应用内存泄漏排查的关键一步——heap dump的获取与解析。作者指出，当需要定位堆内存被何种对象占满时，常规的jstat监控已力不从心，此时获取一份精确的堆内存快照（Heap Dump）就成了分析的核心。 文章系统梳理了触发dump的几种实战方法：可以直接使用jmap命令行工具，或通过jconsole的图形界面操作；更稳妥的方案是在应用启动时配置JVM参数`-XX:+HeapDumpOnOutOfMemoryError`，让它在OOM发生时自动生成现场。文中也提及了hprof，但明确指出其严重拖慢JVM性能，仅适用于调试环境。 在分析环节，作者对比了三款主流工具。IBM HeapAnalyzer能够直观列举堆内存使用状况，定位泄漏源头。JDK自带的jhat则将堆对象转为HTML页面展示，并支持OQL查询语言进行深度探查。而Eclipse Memory Analyzer (MAT) 作为一款功能强大的图形化工具，集成了从获取到分析的完整流程，适合快速诊断。文章最后还补充了一个实用细节：对于NIO等框架直接向操作系统申请的堆外内存，需通过`-XX:MaxDirectMemorySize`参数单独配置与监控。
Java陷阱(2010版)
这篇讲的是作者从开源许可协议立场出发，对Java平台开放性的深度反思。文章以IBM宣布转向OpenJDK、Oracle起诉Google Android侵权等事件为背景，指出Java生态在Sun/Oracle主导下的控制问题——尤其是TCK许可条款长期限制Apache Harmony等替代实现，导致Java世界缺乏像Python、Ruby、JavaScript那样多样化的开源实现。 作者的核心观点是：Java已成为一个由单一公司（Oracle）掌控的“陷阱”。与CPython/PyPy、MRI/JRuby等多实现并存的语言不同，Java开发者实质上被困在Oracle决定的技术路径和许可框架中。尽管有IBM等巨头投入，但平台创新和社区自由度远不及其他开源语言生态。 文章最终向开发者抛出一个关键问题：当你选择技术平台时，它是否真正开放、鼓励创新，还是受制于某家公司的意志？这种对技术选型背后“自由性”的拷问，在云计算和开源协议日益重要的今天，依然具有现实的警示意义。
Java 常量值修改后不起作用
这篇文章讲述了一个看似简单却容易让Java新手困惑的“灵异事件”：为什么修改了代码中的常量值，重新部署后却毫无效果？ 问题出在一位开发者修改了一个 `static final` 变量，本地测试一切正常，但代码提交到服务器后却不生效。作者通过SVN对比版本差异，并敏锐地捕捉到关键点：虽然常量所在的Java文件被修改了，但引用该常量的另一个Java文件并未被改动，因此服务器上并没有重新编译它。 根本原因在于Java编译器的机制：它会将 `static final` 常量的值在编译期直接“内联”到引用它的字节码中。这意味着，运行时系统读取的是编译时写死的旧值，而不是变量引用。所以，只要没有重新编译那个“未被修改”的引用文件，它就一直会使用过时的常量值。 解决方法很直接：删除服务器上过时的 `.class` 文件，让项目彻底重新编译即可。文章也顺带提到了Eclipse等IDE编译器与标准编译器在行为上的细微差异，这可能是本地测试无误的另一个原因。对于新人而言，这个由编译器优化行为导致的陷阱确实隐蔽，容易让人在调试中耗费大量时间。
五四陈透过PHP看JAVA系列：strtotime
这篇来自五四陈科学院的对比文章，聚焦于PHP与Java在处理日期时间时的核心差异。作者从PHP中简洁强大的`strtotime`函数入手，它能直接将如“2010-3-3 3:3:3”的字符串解析为Unix时间戳，在PHP应用中常与MySQL的int(10)字段搭配，进行高效的时间比较与查询。 转向Java，对应的`SimpleDateFormat`方法则显得更为繁琐，需要显式解析、类型转换（将毫秒除以1000）以及异常处理。文章同时指出，由于Java的JDBC对类型要求严格，其项目中通常不会用整型字段来替代datetime类型。 文章还延伸讲解了反向操作：在PHP中用`date()`函数、在Java中用`SimpleDateFormat.format()`将时间戳格式化为可读日期。尤其点明了Java中必须注意将时间戳转换为long类型，否则计算会出错。通过这些具体的代码对比，清晰展现了两种语言在设计哲学和应用场景上的不同侧重。对于跨语言开发的读者，这种具体对比能带来直接启发。