CoderCoding的博客

上文《一起学Java(21)-[配置篇]Gradle控制台乱码问题配置和解决》中，我们解决了Gradle控制台字符乱码问题，这个问题实际是在研究Java String的字符编码机制时产生的。本文回归正题，研究下Java中String的字符编码和代理对机制。中，我们解决了Gradle控制台字符乱码问题，这个问题实际是在研究Java String的字符编码机制时产生的。一起学Java(22)-[JDK篇]学习Java中String的字符编码和代理对机制 | OneCoder。

在《一起学Java(18)-[配置篇]一个诡异(有趣)的Gradle Wrapper问题》中，我们解决了一个有趣的Gradle Wrapper使用问题，这次我们在研究Java String编码的时候，又遇到了Gradle使用中的控制台乱码问题，遂记录并分享问题的现象和解决的过程。中，我们解决了一个有趣的Gradle Wrapper使用问题，这次我们在研究Java String编码的时候，又遇到了Gradle使用中的控制台乱码问题，遂记录并分享问题的现象和解决的过程。

覆盖率反映了测试用例对代码的覆盖程度，能够帮助我们发现潜在的测试盲区，确保代码的每个部分都得到了适当的验证。为了更好地分析代码覆盖率，我们可以使用像 JaCoCo 这样的工具，它可以自动生成详细的覆盖率报告，帮助开发者直观地查看哪些代码已经被测试覆盖，本文将详细介绍如何在 Gradle 项目中集成 JaCoCo 以及如何生成代码覆盖率报告。覆盖率反映了测试用例对代码的覆盖程度，能够帮助我们发现潜在的测试盲区，确保代码的每个部分都得到了适当的验证。

在研究JUnit使用的时候，遇到了一个有趣的Gradle Wrapper使用问题，经过若干天的研究，终于找到并解决了问题，记录分享如下，这也是我们一起学Java过程中遇到的问题。在研究JUnit使用的时候，遇到了一个有趣的Gradle Wrapper使用问题，经过若干天的研究，终于找到并解决了问题，记录分享如下，这也是我们一起学Java过程中遇到的问题。一起学Java(18)-[配置篇]一个诡异(有趣)的Gradle Wrapper问题 | OneCoder。

在上一篇文章中(《一起学Java(16)-[测试篇]教你知道什么是单元测试，单元测试的特点以及Java主要的单元测试框架》)，我们介绍了什么是单元测试，单元测试的特点以及Java主要的单元测试框架。其中提到，JUnit是Java世界中最广泛使用且最具影响力的单元测试框架。本文将重点介绍JUnit框架，特别是其最新版本JUnit 5的特性，以及与JUnit 4的主要区别。本文将重点介绍JUnit框架，特别是其最新版本JUnit 5的特性，以及与JUnit 4的主要区别。)，我们介绍了什么是。

看起来好像学习的主题有些跳跃，因为正在研究Java单元测试覆盖率统计相关问题，所以跳到单测这个领域。为了更好理解这个问题，我从什么是单元测试学起，逐步深入到如何做单元测试、单元测试效果如何检查，最后落到Jacoco单元测试覆盖率工具介绍和使用这个主题。为了更好理解这个问题，我从什么是单元测试学起，逐步深入到如何做单元测试、单元测试效果如何检查，最后落到Jacoco单元测试覆盖率工具介绍和使用这个主题。本文主要聚焦什么是单元测试，单元测试的特点以及Java主要的单元测试框架。

中，我们详细介绍了Java8、Java11、Java17等主流Java版本主要新增特性。特性，展开研究一二。

研究完Log4j2与SLF4J集成的原理(一起学Java(13)-[日志篇]教你分析SLF4J和Log4j2源码，掌握SLF4J与Log4j2桥接集成原理)，学习如何真正应用Log4j2。一起学Java(14)-[日志篇]教你用透Log4j2，掌握Log4j2配置原理和实际应用 | OneCoder。，我要对哪些类进行日志记录，记录到哪里，日志记录成什么格式等等。的包并编写完样例代码，运行后你可能会发现没有任何日志输出，这是因为。真正运行起来是需要首先完成日志的基本配置的，也就是告诉。

研究完SLF4J和Logback这种无缝集成的方式()，继续研究Log4j2和SLF4J这种需要桥接集成的方式。

应该是目前使用比较广泛的一个Mybatis分页插件。我在几个项目里都引入了该插件。今天偶然阅读其源码，却发现了一个不小的问题。注：我阅读的是最新的4.1.3的源码。

在测试的过程中，有人提到，想要获取ApplicationContext实例。于是，添加了对ApplicationContext的注入。其实，Spring中早已直接提供了更加方便使用的基类：AbstractJUnit4SpringContextTests。JUnit单元测试用例中使用Spring框架，之前我的使用方式很直接。

最近在学习Spring源码的过程中，遇到了spring-asm工程的重新打包的问题，于是突然就想研究一下asm这个开源字节码操作工具。对于开源产品，我的一贯风格就是通过其官方提供的源码版本管理地址(svn/git等)，直接下载最新代码，构建Java工程，直接通过工程依赖的方式研究学习。废话不多说，进入正题。所以，立即动手，我先新建了一个待读取的类。对于开源产品，我的一贯风格就是通过其官方提供的源码版本管理地址(svn/git等)，直接下载最新代码，构建Java工程，直接通过工程依赖的方式研究学习。

一个任务的日志信息会被莫名的拆分到两个不同目录中。经过分析，首先怀疑的是MDC没有清理的问题，这也是最直观的问题。由于线程会被重用，而MDC是绑定在Threadlocal上的，所以如果没有清理，是会造成上述问题。但是在代码检查中发现在线程的开始，是重新设置过MDC信息的。经过分析，首先怀疑的是MDC没有清理的问题，这也是最直观的问题。由于线程会被重用，而MDC是绑定在Threadlocal上的，所以如果没有清理，是会造成上述问题。但是在代码检查中发现在线程的开始，是重新设置过MDC信息的。

虽然log4j2 目前还是beta版，不过OneCoder已经忍不住要尝试一下。跟使用log4j 比起来，上手上主要的区别有。1、依赖的jar包。使用slf4j+log4j2 时，依赖的jar包如下：(gradle配置，Maven对照修改即可)没注意观察，还自以为配置文件还是log4j.xml，结果怎么都不管用。默认搜索的配置文件名字变为log4j2或log4j-test开头的配置文件，这个变化，让。使用slf4j+log4j2 时，依赖的jar包如下：(跟使用log4j 比起来，上手上主要的区别有。

日志是项目中必用的东西，日志产品里最普及应该就是log4j了。(logback这里暂不讨论。) 先看一下常用的log4j的用法，一般来说log4j都会配合slf4j或者common-logging使用，这里已slf4j为例。最直接的用法就是在每个需要记录日志的类里，构造一个属于自己类的log实例，实际上很多著名的开源项目也是这么做的。

还是OneCoder在项目中沙箱的问题，用classloader隔离做的沙箱，反复运行用户的任务，出现永生区内存溢出： java.lang.OutOfMemoryError: PermGen space 这个问题在tomcat重复热部署的时候其实比较常见。道理简单，但是实际项目中，寻找这种可能情况就复杂的多了。ClassLoader加载试验 试验思想，基本思想就是循环创建Classloader手动加载包，并通过反射调用包中的代码，考察在外部loader有无引用的情况下，PermGen区的变化情况。

在项目里需要分类收集处理日志信息，使用log4j的MDC在线程中添加分类信息。不过最近却出现日志信息记录错误的情况，具体来说，就是会出现本来是属于下一个分类的一部分信息莫名的记录到上一个分类的日志文件中了。其实，最开始暴露给我们的现象是，在日志清空后，第一次运行任务，会出现两条日志。不过最近却出现日志信息记录错误的情况，具体来说，就是会出现本来是属于下一个分类的一部分信息莫名的记录到上一个分类的日志文件中了。其实，最开始暴露给我们的现象是，在日志清空后，第一次运行任务，会出现两条日志。

​一个小问题，却让我感觉到，现在真正动脑的人很少。。我来说说吧。今天遇到一个小问题，log4j输出到文件乱码，控制台正常。显然是编码问题导致。Google一搜，几乎一水的说：

​继续完成上篇(一起学Java(11)-[日志篇]教你分析SLF4J源码，掌握Logger接口实现类加载原理)留给自己的任务，研究Logback是如何和SLF4J无缝集成的。

​最近各种事情很忙，今天继续。在第十篇(一起学Java(10)-为项目引入Log框架(Log篇二-引入SLF4J接口层框架))中，我们为项目(https://github.com/lihongzheshuai/java-all-in-one)引入了SLF4J和Logback框架，按计划通过阅读源码研究下SLF4J的实现原理。

​在上一节一起学Java(9)-为项目引入Log框架(Log篇一-框架演进和设计逻辑中，我们已经理清了Java日志框架的演进过程、设计思想和核心框架。从这节开始，进入实战研究环节。​

例如：在生产环境中，开发人员通常无法直接调试代码，日志提供了一个详细的执行轨迹，帮助开发人员重现问题。因此，在进入其他框架和代码研究前，我首先想到的就是先完成项目日志框架的引入，进一步夯实基础工作。例如：在生产环境中，开发人员通常无法直接调试代码，日志提供了一个详细的执行轨迹，帮助开发人员重现问题。因此，在进入其他框架和代码研究前，我首先想到的就是先完成项目日志框架的引入，进一步夯实基础工作。要完成Log框架的引入，首先要弄清楚有哪些框架可选以及框架之间的关系逻辑，进而完成框架对比和选型。

我们的项目的第一个PR比我预想的来的早了很多。)的PR。今天就介绍一下这次PR和项目调整的主要内容。

​在现代软件开发中，README文件是任何项目中不可或缺的一部分。它不仅为用户提供了项目的基本信息，还指导开发者如何使用、安装和贡献代码。其实，早在2014年的文章《为项目编写Readme.MD文件》中，我就提到过关于README的事情。今天为了我们的项目，旧事重提也为让大家再get一个知识点，我们再来说说这个README文件。

​前两篇文章（《一起学Java(4)-java-all-in-one协作项目相关文件研究（Gradle篇-上）》和《一起学Java(5)-java-all-in-one协作项目相关文件研究（Gradle篇-下））》）我们已经完成了对项目中Gradle相关文件的研究，按照计划我们继续研究项目的其他配置文件，主要是Git和IDEA自身两类。

​接上篇《一起学Java(4)-java-all-in-one协作项目相关文件研究（Gradle篇-上）》，本文继续研究项目中Gradle相关文件。​

​将思绪拉回java-all-in-one项目，如果你fork并下载了代码，你会看到在项目中除了HelloWorldMain代码外，还存在很多文件。如果你并不了解他们的作用并有足够的好奇心，那你应该想要知道他们的作用。带着好奇，今天我也来研究一下，先从Gradle相关的开始。​

在第一步创建的项目（java-all-in-one）项目里，我们提到了使用Gradle作为项目构建工具。看到这里，不知道你是否有疑惑，什么是项目构建工具。Java项目常用构建工具有哪些？都有什么特点？

​在第一步中（一起学Java(1)-新建一个Gradle管理的Java项目）我们已经完成了项目的创建并托管到了Github上。现在自然要首先解决同学们如何下载代码和进行代码同步更新和联系的问题。这就涉及到Git的fork理念和协作模式的问题。具体介绍如下。​

本文讲述的是Java中try finally代码块执行顺序，和当其存在于循环中的时候的跳出和执行问题。白话，也要简化，一段代码，来说明问题

关于”白话”, 偶然想到的词。目的就是用简洁，明快的语言来告诉您，我所知道的一切。Java中的线程分两类，用户线程和守护线程。

更新节奏缓慢，因为每晚学习注意力不够集中，学习进展缓慢。本还给自己找了一大堆其他理由，但摸着良心问自己，似乎只有这个理由说的通。

距离上一篇博文已经过去了半个多月。这期间有一周多的时间用在了准备单位举办的英语竞赛上。余下的时间沉迷于陪孩子玩耍和睡觉，日复一日。

五六年过去了，Netty早已发展到了4.x系列，好奇也好，求知也罢，我打算重学Netty，虽然严格来说，我已不是IT从业人员，但我仍希望保留对技术的热爱与追求。

最近很多人问我有没有Netty4的Hello World样例，很早之前知道Netty要出4，当时只知道4的包名完全边了，因为Netty从JBoss中独立出来了，并采用了新的netty.io的域名，但是没想到代码也有这么大的调整。

​有一段事件没有更新文章了，各种原因都有吧。搬家的琐事，搬家后的安逸呵呵。不过，OneCoder明白，绝不能放松。对于Netty的学习，也该稍微深入一点了。

​如果您持续关注OneCoder，您可能会问，在《Java NIO框架Netty教程(十四)- Netty中OIO模型(对比NIO)》中不是说下节介绍的是，NIO和OIO中的worker处理方式吗。这个一定会有的，只是在研究的过程中，OneCoder发现了之前遗留的文件传输的代码，所以决定先完成它。

这个周末搬家，并且新家目前还没有网络，本周的翻译的任务尚未完成，下周一起补上，先上一篇OIO和NIO对比的小研究。

​在上节(《Java NIO框架Netty教程(十二)-并发访问测试(中)》)，我们从各个角度对Netty并发的场景进行了测试。这节，我们将重点关注上节最后提到的问题。在多线程并发访问的情况下，会出现错误警告。本文继续研究具体原因。

​写在前面：对Netty并发问题的测试和解决完全超出了我的预期，想说的东西越来越多。所以才出现这个中篇，也就是说，一定会有下篇。至于问题点的发现，OneCoder也在努力验证中。