10km的专栏

摘要：Java中HashMap允许null键值，但使用Collectors.toMap()时遇到null值会抛出NullPointerException。这是因为内部使用的merge方法明确禁止null值。解决方案包括过滤null值、传统循环、自定义收集器、compute方法或第三方库。最佳实践建议根据场景选择方案，代码审查时注意危险模式，并推荐使用实用工具方法处理包含null值的映射情况。

本文对比了Java中实现线程安全延迟加载的两种方案：经典的双重检查锁定和现代的原子化条件更新。通过Redis参数管理类的示例，分析了两种方案的实现方式、优缺点及适用场景。双重检查锁定性能优化但代码冗长，而原子化条件更新简洁现代但需要函数式编程基础。文章指出两种方案性能差异不大，选择应基于团队偏好和维护需求，并强调理解实现原理和正确处理副作用操作的重要性。最终结论是两种方案都有效，开发者应根据具体情况选择最合适的实现方式。

本文介绍了如何扩展json-path库以支持fastjson解析器。通过实现JsonProvider和MappingProvider核心接口，创建FastjsonJsonProvider和FastjsonMappingProvider类，利用fastjson的高性能JSON处理能力。同时设计了XJsonPathConfiguration来自动检测和配置默认解析器，优先级为fastjson>jackson>gson等。该方案使项目能继续使用json-path查询功能，同时享受fastjson的性能

本文介绍了Java正则表达式在高频场景下的性能优化方案。首先分析了String类正则方法频繁创建Pattern实例的性能问题，然后提出三种优化方法：使用静态Pattern常量避免重复编译、用Guava工具类替代简单正则操作、采用CharMatcher处理字符匹配。通过实际代码示例展示了如何优化配置解析和字符串处理场景，建议将重复使用的正则表达式定义为静态常量，并针对简单操作优先选择专用工具类。这些优化措施可以在保持功能的同时显著提升性能。

Apache Commons Configuration2提供了强大的占位符功能，支持在配置值中引用其他属性或外部值。基本语法为${前缀:键名}，系统会根据前缀查找对应的Lookup实现获取实际值。框架内置多种Lookup实现，如base64编解码、环境变量、Java系统属性等，通过DefaultLookups和DefaultStringLookup提供。开发者也可自定义Lookup接口实现并注册到配置系统中，扩展占位符功能。

本文介绍了如何在Microsoft Thrifty客户端中添加SSL/TLS支持。通过扩展Thrifty的传输层，利用Java内置SSL功能实现安全通信。核心组件包括SSLContextFactory、PemReader和扩展的ClientFactory，支持从PEM证书创建SSL上下文。使用时需配置SSL参数并应用到ClientFactory，注意事项包括使用强加密套件和有效证书。该方法在保持Thrifty简洁API的同时实现了安全通信，完整代码可在xthrift仓库的ssl分支获取。

本文探讨了JSQLParser中TablesNamesFinder类的核心原理与应用。作为SQL解析的关键工具，TablesNamesFinder通过访问者模式遍历AST，收集SQL语句中的表名信息。文章分析了其继承关系（实现多个访问者接口）、核心功能（表名收集、可配置性）及与CCJSqlParserVisitor的关系。典型应用场景包括表依赖分析、SQL安全检查、格式化等。最后通过CanonicalColumnVisitor示例展示了如何扩展该类实现列名规范化（添加表前缀/别名），为SQL处理提供灵活解决

本文介绍了Java 8 Stream中Collector的高级用法，通过Collector.of方法实现定制化集合转换。作者首先展示了基础用法如Collectors.toSet()和Collectors.toCollection()，然后重点讲解了如何利用Collector.of方法的finisher参数创建不可变集合。文章提供了三个实用示例：1）将Stream转换为不可变LinkedHashSet；2）使用Guava的ImmutableSet.Builder构建不可变集合；3）创建不可变LinkedHas

Maven Central仓库服务迁移后，项目发布配置需更新：1)删除原有distributionManagement配置；2)添加central-publishing-maven-plugin插件（建议版本0.7.0），配置服务器ID与settings.xml匹配；3)设置autoPublish=false进行手动验证发布。发布流程：先执行mvn clean deploy上传，再登录Sonatype Central控制台完成验证和发布操作。注意需在settings.xml配置账号Token，并确保Mave

aocache通过注解方式定义方法启用计算缓存，对于每一个切入点而言，在编译期就已经定义了缓存的配置（weakKeys，maximumSize，expireAfterAccess等等）。但实际应用场景中，通过AOCache 性能分析结果，可能会发现有些配置对切入点的综合性能提升并不理想，需要调整，这种情况下，如果切入点并不在当前项目，想要根据应用场景修改切点，就会很麻烦。所以需要一种切入点(JoinPoint)自定义配置机制，可以允许通过外部以切入点配置文件的形式对切入点的配置进行调整。通过。

通过正确的参数分析处理策略，实现了安全可靠的JoinPoint参数封装。该方案已在中验证，成功解决了多参数场景下的自动包装问题。

最近的工作与aspectj切面技术相关，为了实现零依赖，将aspectjrt包也重定位包名打到项目jar包中，但带来的问题因为aspectj相关包名被重定位了该项目也不能作为切面库使用，所以又想了一个更复杂的方案来解决这个问题，其中就需修改javac编译生成.class文件，将.class字节码中所有引用的aspectj类的包名进行修改重定向到新的包名。在DeepSeek的帮助下，已经实现了需求，此文作为技术总结，说明如何基于ASM实现.class引用包名的重定向。

最近的工作中设计了一个maven插件,需要在插件执行时的增加新的依赖库，本文作为总结，说明如何在插件执行时自主注入新的依赖库。

是一个典型的“文档描述 < 源码真相”案例。仅当时生效仅影响生成的 POM 文件，不控制 JAR 打包用于保留provided依赖在精简 POM 中的元数据它只是 POM 文件的管家，不是 JAR 打包的搬运工。

- 新方案：添加默认值 --> < properties fileName = " ${sys:user.home}/${const:com.mycompany.GlobalConfig.HOME_FOLDER}/${env:XKE_RT_PROPERTIES:-} " config-name = " runtimeConfig " config-optional = " true " />

最佳实践建议：尽量使用子类模式：如保持类型安全结合TypeToken使用：借助Guava的强大类型推断能力注意类型边界：明确理解extends和super的行为差异防御式编程：在反射访问时做好类型校验性能考虑：TypeToken的内部缓存机制保证了重复使用的性能，但在高频场景建议缓存生成的WildcardType实例。通过本文的代码示例和原理分析，相信读者已经掌握了使用TypeToken优雅处理通配符类型的诀窍。这个技巧在处理复杂泛型系统时显示出极大的威力，值得加入每个Java开发者的工具箱。

Guava TypeToken是一个功能强大的泛型解析工具。可以很简单的实际这个需求。这样的带泛型参数的抽象类，如何在类初始化时得到F,T对应的类型？构造方法时已经完成了对F类型参数的解析，保存到。

使用ActiveMQ（5.14.5）作消息系统服务的场景下，当我用Apache Qpid Proton发送消息(使用AMQP协议)发送JMS消息，用Paho MQTT接收消息的时候，收到的消息前面总是有一串乱码，大概就是这样：4Sp?ASr??

之前写过一篇博客介绍了如何在Spring下集成commons-configuration2，通过来管理spring环境的所有配置。当时并没有介绍如何支持yaml格式的配置文件。Spring本身默认是用application.yaml来提供系统配置定义的。如果commons-configuration2能支持YAML格式，就更方便了。commons-configuration2其实也提供了对YAML格式文件的原生支持。

我的工作平台主要是Windows，需要经常发布版本到maven中央仓库(mvn release:perform),这个发布动作我多数是在Bit Bash环境下完成的。上传到maven中央仓库的文件都需要插件签名：

是一个我维护了好多年的一个基础项目,编译目标为Java 1.7现在整个团队的项目要做Java 9以上的技术迁移准备,就需要对这个在内部各项目中被广泛引用的基础项目进行改造,以适合Java 9的模块化规范。

方案二的好处显而易见,因为插件内部就能搞定项目的依赖库,如本例中,自定义插件不再需要通过定义一个参数(classpath)从外部传递项目依赖,也不再需要在pom.xml中定义maven-dependency-plugin插件获取classpath,简化了自定义插件的使用,而且场景适应性更好.

方案一和方案二哪种更适合你?一般情况下两种方案都没有问题.我对于我来说,因为应用在maven插件中,所以只能选择方案二.个人认为方案二通用性更好.但是在只能通过String类型参数传递Doclet的的场景,也只能使用方案一,那么就不建议使用静态字段将传递出去由外部完成业务逻辑的方式,而是应该在自定义Doclet内部完成所有的业务逻辑更稳妥些.

是我最近写的一个基于Java 9 的javadoc读取java代码注释的工具。在基于Java 9(我用的编译器JDK 19)编译时，插件在执行报了一堆错误：显示所有的模块在都不能被识别,这些模块名都是javadocreader9的中定义的模块名。如下是定义如下是javadocreader9的pom.xml片段：

我用的maven版本是3.6.3，在JDK19环境下今天执行一个项目编译的时候报错了，如下是详细的错误信息，显示是。这个插件版本兼容问题，需要升级版本才能适应JDK 9以上的环境，这些配置在jdk8环境下编译都是正常的，所以我想到可能是。)查到这个插件3.x的最新版本是3.15.1。,果然错误消失，问题解决。在maven中央仓库(

javadoc官方文档中关于参数说明中明确说明路径分割为引号(‘;’)取自但经在linux下验证实际测试，显示这个说明是不正确的，参数的路径分割符应该使用系统的路径分割符。在 Windows 系统中，路径分隔符是分号 ‘;’，而在 Linux 系统中则是冒号 ‘

JDK9 javadoc API获取的源码注释结构化数据中，但是，JDK 9并没有提供从Java反射类型到java Doc类型的互操作。如果要想在TypeElement中获取指定方法的的注释对象，就要自己实现这个查找功能。本文介绍如何在TypeElement中查找指定方法(Method)对应的对象。

上一篇博客介绍了JDK9下javadoc API的基本使用方法。本文进一步示例说明如何通过使用遍历语法树的方式更精确获取注释对象中子对象的方法。

简单介绍了通过javadoc API读取源码注释的流程。那时还是用JDK 1.8。但是在JDK9环境下JDK 1.8的那一套API就不能用了。JDK 9提供了一套新的javadoc API实现注释代码的读取，即模块。本文说明如何基于来读取源码的注释。

最近在执行maven release:perform 发布版本到maven中央仓库里出了如题的错误详细输出如下解决的办法也很简单，将pom.xml中的版本从默认的3.3.0降下来，改为3.2.1,这是maven 3.3.0的问题，也可能算是一个bug,详细说明参见下面《参考资料》提供的链接

之前写过一篇博客介绍了如何在在spring的拦截器一层获取POST请求参数。当我在thrift环境使用ThriftEventHandler拦截请求获取请求参数，也遇到了类似的问题：这个阶段，因为请求方法的参数还没有被反序列化，所以要想获取HTTP的请求参数，就要自己从HttpServletRequest中获取。要从请求内容里获取参数，就要从TProtocol里获取到，然后解析出数据就可以了。

如果一个方法是桥接方法，那么因为这个方法是由编译器自动生成的，所以它的方法参数名是无意的arg0,arg1。所以对于一个由编译器生成的桥接方法，如果要获取它的参数名，需要得到它实际调用的有原始方法，也就是被桥接方法，库中的同名方法，这是我从spring-core 5.3.12提取出代码，重新封装为适用JDK1.7环境的库。说实话，这个逻辑很挺复杂，但好在有人已经帮我们做了这些工作，如果在spring环境，可以使用spring的。对象中的name就是这些意义的名字。方法就能得到正确被桥接方法。

经此一役,深刻体会antlr4虽然好学好用,但其面向通用场景生成的JSON词法语法分析器,与手撸的针对场景优化过的JSON解析器在性能上差距还是挺大的.

spring的拦截器(HandlerInterceptor)机制工作在收到HTTP请求之后，参数解析（反序列化）之前阶段。所以拦截器(HandlerInterceptor)中获取POST请求参数本身并不是问题，问题就是要解决。中就可以正常读HttpServletRequest的InputStream，而不影响后续的参数反序列化了。这个阶段，因为请求方法的参数还没有被反序列化，所以要想获取HTTP的请求参数，就要自己从。是单向的，一次性的，如果在拦截器中直接调用。获取了数据，后续方法调用解析参数时再调用。

本文适用于所有AspectJ与Spring AOP混用的场景。Spring AOP 是基于动态代理的实现AOP，基于 JDK代理和CGLib代理实现运行时织入（runtime weaving）。Spring AOP的切面定义沿用了ASpectJ的注解体系，所以在Spring体系中注解定义切面的方式与ASpectJ完全兼容， 但如果一个项目中有Spring 切面定义又要使用静态态织入(CTW)的情况下，就会存在冲突问题。如下面的示例，项目中定义了一个Spring AOP切面，拦截所有带注解的服务方法。

aoocache发布第一个版本0.1.0时，没有考虑到使用aocache的项目对方法缓存的控制需求。给同事做培训时，同事提到这个需求，他希望能够有方法主动去清理指定方法的缓存：他的数据是由其他服务启动时提供的，他的方法要根据这些数据进行复杂计算返回结果。如果其他服务重启了，会刷新这些数据，如果使用aocache提供的方法缓存机制，他就需要有办法能清理这些缓存。

之前一篇博客介绍了使用注解实现单实例缓存的方式，同时也指出了这种方式的使用限制，就是这个注解定义的构造方法，不能再创建出新实例。为了更灵活方便的实现单实例。aocache最新版本0.4.0增加了支持单实例缓存的工具类SingletonSingleton提供了两种方法分别提供弱引用单实例缓存，和普通强引用单实例。

在之前的博文中，实现了对MySQL数据库存储的WKB数据到JTS Geometry对象之间的转换。当我们从数据库中得到的Geometry对象后，我们需要把它提供给前端时，就需要将它转为JSON格式，或从前端将JSON数据反序列化为Geometry对象。本文说明使用JSON工具库Fastjson如何实现这个过程。JTS Geometry对象不是标准的Java Bean不能自动被Fastjson执行序列化和反序列化。所以我们需要为 Geometry对象实现自定义的序列化器和反序列化器。

在上一篇博文中，实现了对MySQL数据库存储的WKB数据到JTS Geometry对象之间的转换。当我们从数据库中得到的Geometry对象后，我们需要把它提供给前端时，就需要将它转为JSON格式，或从前端将JSON数据反序列化为Geometry对象。本文说明使用JSON工具库Jackson如何实现这个过程。JTS Geometry对象不是标准的Java Bean不能自动被Jackson执行序列化和反序列化。所以我们需要为 Geometry对象实现自定义的序列化器和反序列化器。

sql2java是我几年年开始写的一个sql2java是一个轻量级数据库(SQL)访问代码(java)生成器。这几年一直在根据工作需要维护升级，最近的项目中需要对数据库的记录提供导出excel的功能。就开始学习apache的POI，将它封装成一个通用库成为sql2java下的子项目[sql2java-excel],本文开始介绍sql2java-excel的spring支持.......