小菜鸟

java菜鸟号正在起航

0%

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 4.9k 阅读时长 ≈ 4 分钟

Log4j2 自动删除日志文件：配置策略与最佳实践

线上系统日志文件持续增长，若不及时清理会导致磁盘空间耗尽，影响服务稳定性。Log4j2 的DefaultRolloverStrategy中内置了Delete操作，支持在日志滚动时自动清理过期文件，无需手动干预。本文详细解析自动删除配置的核心参数、注意事项及实战案例。

自动删除日志的核心原理

Log4j2 的自动删除功能依赖DefaultRolloverStrategy中的<Delete>标签，其工作机制是：
当日志滚动触发时（如达到时间或大小阈值），执行预定义的删除规则，清理符合条件的旧日志文件。

  • 触发时机：与日志滚动同步，仅在滚动发生时执行删除（避免频繁检查磁盘）；
  • 删除规则：通过<IfFileName>（文件名匹配）和<IfLastModified>（修改时间匹配）组合筛选文件；
  • 安全性：支持配置目录扫描深度和文件匹配规则，避免误删非日志文件。

<Delete>标签核心配置参数

<Delete>标签的配置决定了删除范围和条件，关键参数如下：

参数名 作用说明 示例值
basePath 扫描的根目录（绝对路径或通过变量指定，如${LOG_HOME}） /data/logs/app
maxDepth 目录扫描深度（0= 仅basePath本身，1= 包含直接子目录，2= 包含孙子目录） 2
<IfFileName> 文件名匹配规则（支持通配符*和?，glob属性指定模式） glob="app-*.log.bz2"
<IfLastModified> 文件最后修改时间条件（age属性指定过期时间，单位d天、h小时等） age="30d"（30 天前）

自动删除配置示例与解析

以下是生产环境常用的自动删除配置，结合日志滚动策略实现 “按时间归档 + 大小限制 + 自动清理” 的完整流程：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 13k 阅读时长 ≈ 12 分钟

Log4j2 日志文件滚动详解：触发策略与滚动策略的完整实践

在生产环境中，日志文件若持续写入会导致单文件体积过大，不仅占用大量磁盘空间，还会导致日志查询和分析效率低下。Log4j2 的RollingFileAppender通过日志滚动机制，按时间、大小等条件自动分割日志文件，是解决这一问题的核心方案。本文详细解析日志滚动的触发策略（TriggeringPolicy）和滚动策略（RolloverStrategy），并结合配置示例说明实战用法。

日志滚动的核心概念

日志滚动的本质是：当满足预设条件时，RollingFileAppender停止向当前日志文件（fileName指定）写入，转而创建新文件继续写入，并对旧文件按规则命名和归档。核心依赖两大组件：

  • 触发策略（TriggeringPolicy）：决定 “何时” 触发滚动（如文件达到 1GB、时间到凌晨 0 点）；
  • 滚动策略（RolloverStrategy）：决定 “如何” 滚动（如旧文件命名规则、保留数量、自动清理）。

触发策略（TriggeringPolicy）：何时触发滚动

触发策略定义滚动的触发条件，Log4j2 提供 5 种常用策略，可单独或组合使用（通过<Policies>标签组合）。

1. TimeBasedTriggeringPolicy：基于时间触发（最常用）

核心逻辑：根据日志文件命名格式（filePattern）中的时间粒度，定时触发滚动（如按天、按小时）。

关键特性：
  • 依赖filePattern中的时间占位符（如%d{yyyyMMdd}表示按天，%d{yyyyMMddHH}表示按小时）；
  • 滚动时机由时间粒度决定，与日志是否写入无关（即使无日志，到时间也会触发空文件滚动）；
  • 支持interval（滚动间隔）和modulate（时间对齐）参数。
配置示例：
阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 2.2k 阅读时长 ≈ 2 分钟

深入解析 “nf_conntrack: table full, dropping packet” 报错及解决方案

在高并发网络场景中，Linux 服务器有时会出现 nf_conntrack: table full, dropping packet 错误，导致应用连接失败（如 MySQL 通信链路中断）。本文将从原理、参数、解决方案三个维度详细解析该问题，帮助彻底解决此类网络故障。

问题本质：连接跟踪表耗尽

1. nf_conntrack 模块的作用

nf_conntrack 是 Linux 内核中的连接跟踪模块，主要用于：

  • 跟踪网络连接的状态（如 TCP 连接的建立、关闭、超时等）；
  • 在 NAT（网络地址转换）场景下，记录源 / 目标 IP、端口等信息，确保数据包能正确转发；
  • 为防火墙（如 iptables）提供连接状态信息（如 --state ESTABLISHED 规则）。

该模块通过哈希表存储连接信息，每条记录包含连接的源地址、目标地址、端口、协议、状态等关键信息。

2. 报错原因：哈希表容量不足

当系统中的网络连接数量超过 nf_conntrack_max（哈希表最大条目数）时，哈希表会被填满，新的连接无法被跟踪，内核会丢弃新连接的数据包，从而触发 nf_conntrack: table full, dropping packet 错误。

在高并发场景下（如用户提到的 “访问量较高的项目”），默认参数极易触发该问题：

  • 默认 nf_conntrack_max 通常为 65535（受系统内存限制，小内存机器可能更低）；
  • 默认 nf_conntrack_tcp_timeout_established（已建立连接的超时时间）为 432000 秒（5 天），意味着即使连接已闲置，仍会在哈希表中保留 5 天，长期占用条目。

关键参数解析

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 7k 阅读时长 ≈ 6 分钟

视频缩略图生成全指南：基于 JavaCV 与 FFmpeg 的实战方案

在视频管理系统中，缩略图是提升用户体验的关键元素，用于列表预览、详情页展示等场景。本文将详细讲解如何使用 JavaCV（封装 FFmpeg） 实现视频缩略图生成，包括依赖配置、核心代码实现、优化技巧及常见问题解决，帮助你快速集成视频缩略图功能。

技术选型：为何选择 JavaCV + FFmpeg？

生成视频缩略图的方案有多种，对比后 JavaCV + FFmpeg 成为首选：

方案 优势 劣势
JavaCV + FFmpeg 支持几乎所有视频格式，处理能力强，可定制化高 依赖稍大，需理解基础视频概念
Xuggle 轻量易用 已停止维护，对新格式支持不足
本地调用 FFmpeg 命令 无需 Java 依赖，直接复用 FFmpeg 功能 跨平台兼容性差，进程管理复杂
纯 Java 库（如 MP4Parser） 无 native 依赖，部署简单 仅支持少数格式（如 MP4），功能有限

结论：JavaCV 基于 FFmpeg 封装，兼顾功能完整性和 Java 易用性，适合生产环境使用。

环境配置与依赖引入

Maven 依赖配置

JavaCV 通过 Maven 引入，核心依赖包括 javacv 和 FFmpeg 平台包（自动适配不同操作系统）：

阅读全文 »

发表于 更新于 分类于 阅读次数： Valine：
本文字数： 1.9k 阅读时长 ≈ 2 分钟

线上问题排查全流程：从现象到根源的系统分析

线上系统出现故障时，快速定位问题根源是核心目标。本文基于 “分层排查、聚焦瓶颈” 的思路，详细介绍从 CPU、内存、网络、磁盘四个维度排查问题的步骤和工具，帮助高效解决线上故障。

第一步：CPU 使用率过高排查

CPU 是系统运行的核心，其使用率过高会直接导致系统卡顿、响应延迟。

确认 CPU 瓶颈

使用 top 命令实时监控 CPU 状态：

1
top  # 进入界面后按 P 键按 CPU 使用率排序
  • 关键指标：顶部%Cpu行的%idle（空闲 CPU 百分比）。
    • 若 %idle 长期 < 10%：表示 CPU 资源紧张。
    • 若 %us（用户态 CPU）或 %sy（系统态 CPU）长期 > 80%：需定位具体进程。

定位高 CPU 进程

  • 在 top 界面中，%CPU 列显示单个进程的 CPU 占用率，记录高占用进程的 PID。

  • 针对 Java 进程，可进一步分析线程栈：

    1
    2
    3
    4
    5
    6
    7
    8
    # 查看进程内线程的 CPU 占用（PID 为目标进程 ID）
    top -Hp PID

    # 将线程 ID 转换为十六进制（用于 jstack 定位）
    printf "%x\n" 线程ID

    # 导出进程栈信息，查找对应线程的调用栈
    jstack PID | grep 十六进制线程ID -A 30

  • 常见原因：死循环、频繁 GC、大量计算任务等，需结合业务代码优化。

第二步：内存不足排查

阅读全文 »