- 博客(1185)
- 资源 (9)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 XXL-JOB分布式任务调度框架
执行批量任务，根据骑手的换电频次（如日换电≥3次=高频用户、30天未换电=沉睡用户）、消费金额、所在城市等维度，更新用户标签，支撑精准运营（如给沉睡用户发优惠券）。执行一次批量任务，遍历离线设备列表（100万+设备），排查超过30分钟未上报心跳的电池/柜机，标记“离线设备”并推送告警（短信/钉钉/企业微信）给运维人员；：针对你百万级设备/订单的批处理，可将任务拆分成多个分片，由多台执行器并行处理，避免单机器性能瓶颈，适配5k+ QPS的高并发平台；
2026-01-22 11:40:23
314
原创 Kafka本身只保证单个分区内的消息是有序的
单分区单线程消费会限制吞吐量，若需高性能，可按业务维度拆分多个分区（比如按订单ID尾号分10个分区），每个分区独立保证顺序，整体提升并发。这三个环节缺一不可，既利用了 Kafka 的分区特性保证消费顺序，又通过数据库的控制确保落库顺序，是分布式场景下保证顺序性的标准方案。：关闭自动提交 offset，仅在落库成功后手动提交，防止消息落库失败但 offset 已提交导致的丢失，或重复提交导致的重复消费。：单个分区仅由一个消费实例的单线程消费，关闭自动提交 offset，落库成功后再手动提交。
2026-01-22 11:40:23
730
原创 全国10亿级流量入口CDN实战指南
CDN在全国300+城市、所有运营商（电信/联通/移动）都放了“缓存节点”，把视频、图片、网页这些高频数据存到节点上，用户就近访问，相当于“家门口取快递”，既快又能分散核心压力。先明确核心认知：10亿级流量入口（日均UV/请求量达10亿级），靠自建服务器完全扛不住，CDN是“必选项”而非“可选项”——它就像全国布局的“流量中转站”，让用户就近取数据，既减轻核心服务器压力，又让用户访问更快。动态流量为主（占比30%+，如直播互动、实时评论）：核心做“动态代理+链路优化”，CDN负责转发请求，不缓存动态数据。
2026-01-20 20:13:36
545
原创 CDN+Nginx百亿级流量架构搭建与Java微服务落地指南
在百亿级流量架构中，针对即时通讯、直播互动、物联网推送等场景，需支撑百万级长连接（TCP/WebSocket），仅靠Nginx难以满足连接数上限与低延迟需求，需构建“Nginx反向代理+Netty服务集群”架构，Nginx负责负载分发、SSL卸载、连接复用，Netty负责核心长连接维护与业务处理，协同实现百万级长连接承载。核心业务域拆分：用户服务（用户登录、信息管理）、商品服务（商品查询、库存管理）、订单服务（订单创建、支付回调）、内容服务（资讯/视频分发），每个服务独立部署、独立扩容，避免业务耦合。
2026-01-20 20:13:36
559
原创 Java代码执行时对象从新生代到老年代的流转过程
弄清楚Java代码执行时对象从新生代到老年代的流转过程，同时明确大对象、永久代、方法区、虚拟机栈这些核心概念的定义和作用，我会结合代码执行的实际场景，用通俗的语言逐一拆解，让你清晰理解每个概念的本质和关联。：Survivor区中相同年龄的对象总和超过Survivor区空间的50%，年龄≥该值的对象会提前进入老年代（比如年龄3的对象占S0区60%，则年龄≥3的对象都进老年代）。老年代专门存储生命周期长的对象（比如全局缓存对象、单例对象），这里的GC频率远低于新生代（只有老年代满时才触发Full GC）。
2026-01-19 08:15:20
335
原创 性能优化修复总结
使用Intersection Observer延迟加载，只在组件可见时才加载数据。：每个沸点都直接渲染了CommentList组件，导致所有评论列表在首屏就加载。对于GET请求，如果已有相同请求在进行，则取消重复请求。：评论列表在组件mounted时就加载，即使组件不可见。：相同的API请求被多次触发（如多个沸点的评论列表）使用请求key（URL+参数）来识别重复请求。：评论区域只在用户点击评论按钮时才显示（：文章列表、专题列表、通知等在首屏就加载。- 同一个沸点的评论列表被请求多次。
2026-01-15 07:45:18
361
原创 提升服务器性能，解决前端首页加载过慢的问题
核心目标是提升服务器性能，解决前端首页加载过慢的问题。我会从Nginx性能调优、静态资源优化、缓存策略、网络传输等多个维度来优化这份配置。并调优：压缩级别设为6（压缩率和性能平衡最佳），覆盖所有前端资源类型，可减少60%-80%的传输体积。SSL和TCP层的优化减少了网络握手和传输延迟，API代理的优化提升了后端响应效率。，这是解决前端加载慢最直接的手段，可大幅减小传输体积；提升服务器性能，解决前端首页加载过慢的问题。提升服务器性能，解决前端首页加载过慢的问题。工具做压力测试，对比优化前后的QPS。
2026-01-15 07:45:18
295
原创 网站性能优化
使用 Intersection Observer API 实现高性能图片懒加载。：通过懒加载和格式转换，减少 50-70% 的 GIF 传输。：自动检测浏览器 WebP 支持，优先使用 WebP 格式。：esbuild（比 terser 快 10-100 倍）：WebP 格式比 GIF/PNG 体积小 30-50%：大型 JS 文件加载时间从 8 秒降低到 2-3 秒。：只加载可视区域内的图片，减少初始加载数据量。Vue 核心库单独打包（vue-core）：按需加载 CSS，减少初始 CSS 体积。
2026-01-15 07:45:18
515
原创 ReentrantLock基础用法示例
基础用法的核心价值是保证多线程对共享资源操作的原子性，替代 synchronized 完成简单同步场景。：ReentrantLock 默认是非公平锁，性能优于公平锁，无需特殊场景（如排队）不要轻易用公平锁。的代码，覆盖「基本加锁释放」「可重入特性」两个核心基础场景，并附带详细注释和运行结果说明。你需要的是 ReentrantLock 最核心的基础用法示例，我会提供。ReentrantLock 基础用法示例（完整可运行）重入的锁要“获取多少次，释放多少次”（示例中。二、极简版基础示例（无重入，快速入门）
2026-01-10 21:12:19
341
原创 Java中ReentrantLock的完整使用指南
相比synchronized提供了更灵活的锁控制能力（公平锁、可中断、超时获取、精准唤醒等）。解决：严格遵循「lock() → try → 业务 → finally → unlock()」。：线程按启动顺序依次获取锁（无插队），但性能略低于非公平锁。示例：获取2次锁，仅释放1次 → 锁计数=1，不会真正释放；解决：仅在“必须按顺序获取锁”时使用公平锁，默认用非公平锁。：非阻塞获取锁，获取成功返回true，失败返回false；重入时需保证「获取次数=释放次数」（否则锁不会真正释放）；
2026-01-10 21:12:19
439
原创 基于Netty的设备接入网关系统实战
本方案完整实现了基于Netty的设备接入网关核心功能，解决了长连接管理、粘包处理、心跳保活、设备认证、集群转发等关键问题，并适配了Redis/MySQL集群保证高可用。本文将完整实现一套企业级设备接入网关，涵盖Netty长连接核心特性（主从Reactor、粘包解包、心跳保活、设备认证）、网关集群、Redis/MySQL集群适配，提供可直接落地的Java代码及全流程说明。：主从Reactor模型，处理设备TCP长连接、粘包解包、心跳、认证。：Netty网关集群+Redis集群（主从+哨兵）+MySQL主从。
2026-01-09 12:53:51
334
原创 Kafka配套的Zookeeper启动脚本
，这个脚本是 Kafka 内置 Zookeeper 的核心启动入口，我先帮你拆解脚本的核心逻辑、关键配置，再结合你之前的场景给出。该脚本是 Kafka 内置 Zookeeper 的标准启动入口，核心是指定配置文件+可选。：Zookeeper 配置文件路径（相对 bin 目录的上级 config 目录）。二、使用该脚本启动 Zookeeper 的正确步骤（适配你的场景）你提供的是 Kafka 配套的 Zookeeper 启动脚本（步骤2：启动 Zookeeper（后台运行，推荐）
2026-01-08 13:09:08
383
原创 完整的Kafka项目启动流程
（从环境清理到验证运行），我会基于你的服务器环境（7.5GB内存、已用5.3GB、无Swap），给出。按上述步骤执行，你就能稳定启动Kafka，且后续可通过日常运维命令管理Kafka服务。步骤4：清空Zookeeper中旧的Kafka元数据（关键！验证关键：进程、端口、日志三者都正常，才算真正启动成功。步骤3：启动Zookeeper（Kafka的依赖服务）步骤6：验证Kafka是否启动成功（3个核心验证）步骤1：进入Kafka安装目录（确保路径正确）二、完整启动步骤（逐行执行，无坑版）
2026-01-08 13:09:08
465
原创 Kafka单节点可承载的数据量-负载均衡能否根据IP路由消费
机械硬盘（HDD）：适合大容量冷数据存储，单盘容量可达 10TB+，但随机读写性能弱<br>- 固态硬盘（SSD）：适合高吞吐热数据，单盘容量 1TB - 8TB，IOPS 是 HDD 的 10 倍以上。HDD 单节点：顺序写吞吐量约 100MB/s - 300MB/s，顺序读约 50MB/s - 200MB/s（适合批量消费、日志采集等场景）。SSD 单节点：顺序写吞吐量约 500MB/s - 1.5GB/s，顺序读约 300MB/s - 1GB/s（适合高吞吐实时计算场景）。
2026-01-07 15:51:35
269
原创 第378集设备服务接入系统Java微服务后端架构实战
后端开发 keywords: 设备服务接入系统,微服务架构,Java实战,设备接入,MQTT,设备注册,设备认证,设备连接管理,设备指令下发,设备数据上报,SpringBoot description: 深入解析设备服务接入系统的Java微服务架构设计，从设备注册认证、MQTT连接管理、设备指令下发、设备数据上报到心跳检测和状态管理，提供完整的企业级设备接入解决方案。：采用微服务架构，通过接入网关、设备服务、指令服务、数据服务协同完成设备接入管理。：负责设备注册、设备认证、设备管理、设备状态维护。
2025-12-05 08:19:24
615
原创 第365集JVM原理架构实战：JVM架构设计、类加载机制与执行引擎完整解决方案
JVM的架构设计、类加载机制、执行引擎、内存模型等核心原理直接影响Java应用的性能、稳定性和可扩展性。本文将深入探讨JVM的原理与架构设计，从JVM架构、类加载机制、执行引擎、内存模型到垃圾回收机制，提供完整的架构师级别JVM原理解决方案。在实际项目中，应深入理解JVM原理，根据业务特点选择合适的JVM配置，建立完善的监控体系，持续优化，确保应用的高性能和稳定性。：理解JVM的整体架构，包括类加载子系统、运行时数据区、执行引擎等核心组件。：理解类加载的过程、类加载器的层次结构和双亲委派模型。
2025-11-13 22:16:18
964
原创 分布式微服务系统架构第174集：kafka硬件配置
（4）compression.type：默认是none，不压缩，但是也可以使用lz4压缩，效率还是不错的，压缩之后可以减小数据量，提升吞吐量，但是会加大producer端的CPU开销。kafka节点，broker核心参数配置，服役新节点，退役旧节点，核心参数配置，再平衡，事务，提高吞吐量，数据精准一次，合理设置分区，单条日志大于1M，服务器挂了，压力测试集群。该时间阈值，默认30s。（3）如果将kafka整个节点误删除，如果副本数大于等于2，可以按照服役新节点的方式重新服役一个新节点，并执行负载均衡。
2025-09-23 00:01:00
1257
原创 分布式微服务系统架构第172集：Kafka、MongoDB、Redis、MySQL
Prometheus + Grafana + Exporters（kafka/mongo/redis/mysql/node）+ 告警通道。，并将 Kafka 拆成 3+ 节点，Mongo 副本集，Redis Sentinel/Cluster，MySQL 主从/MGR。3 台 Kafka、3 台 Mongo、6 台 Redis（3+3）、2–3 台 MySQL。网络：万兆（或 ≥5 Gbps）+ 独立业务网段；数据加密（TLS/DTLS、AES）、身份认证（JWT、证书）、访问控制。
2025-09-22 06:47:42
863
原创 分布式微服务系统架构第171集：数据存储-状态码
在内存数据库方面的另一个优点是， 相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。另外，有时硬件厂商未提供所需版本的Windows下的驱动，也会比较头痛。在西班牙的一些地区开发了自己的Linux发布版，并且在政府与教育领域广泛使用，如Extremadura地区的gnuLinEx和Andalusia地区的Guadalinex。Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
2025-09-14 23:59:43
584
原创 分布式微服务系统架构第170集：Kafka消费者并发-多节点消费-可扩展性
（Leader）：顺序写入日志（先入页缓存→追加到 segment，更新索引），并向 ISR 中的 Follower 复制。举例：峰值 5,000 msg/s，每条处理 20 ms（0.02s），单分区能稳态 500 msg/s，：原 topic/partition/offset/timestamp、异常类名、异常消息等，方便排查。topic、key（可选，决定有序性）、value、headers、timestamp。：把 DLT 导出到仓库（ClickHouse/ES/S3），数据修复后按批重投。
2025-09-07 16:05:41
1354
原创 微信支付（API-v3）标准流程
Java（Spring Boot）下单示例（用官方 SDK，省心）（注意沙箱的密钥与生产不同）；：后台校验回调签名，AES-GCM 解密交易资源，做。：按业务再扩展，依旧围绕「签名、拉起、回调、验签」。：你的服务器向微信「统一下单」接口发起请求，拿到。用于：前端失败但实际已扣款、或回调迟迟未到等。三、后端：统一下单（JSAPI/小程序）四、前端：拉起支付（小程序/Taro）一、整体时序（JSAPI/小程序）一、整体时序（JSAPI/小程序）七、退款 & 回调（API v3）：支付成功后，微信回调你的。
2025-09-05 02:39:47
1017
原创 分布式微服务系统架构第169集：1万~10万QPS的查当前订单列表
即使峰值 10 万 QPS 的查询，也能把“真正落库”的请求稳定压在一个可控水平（例如每秒几百），Mongo 不会被尖峰打穿。：订单创建/状态变化时，只打一把脚本，完成 MSET + EXPIRE + 广播。全 Redis 侧的“闸 + 合并 + 负缓存 + 打散 + 广播 + 异步回源”：把“用户→当前订单ID”“订单详情”维护在 Redis，绝大多数查询不落库。（键模型 + Lua + Pub/Sub/Stream + 用法示例）。”，可以把“防穿透/合并/限流/热键打散/负缓存/失效广播”全放到。
2025-09-04 06:50:15
1194
原创 分布式微服务系统架构第168集：不要让“百万用户”直连 Redis
Redis/网络异常：直接走 L1、返回旧值、或回源 DB + 限流；部署：应用 50 实例（2k QPS/实例），Redis Cluster 6 主 6 从。：L1（Caffeine 30–60s）+ L2（Redis 5–10min），并用。L2：Redis（Cluster/哨兵），较长 TTL（1–10 分钟）L1：应用进程内 Caffeine（纳秒级），短 TTL（几十秒）：命中率、内存、水位、QPS、慢查询、p99、连接数、重连次数；：监控 QPS、延时、内存、命中率、慢日志、连接数、同步延迟。
2025-09-03 20:56:46
1167
原创 分布式微服务系统架构第167集：从零到能跑kafka-redis实战
Netty 接入后，解析为标准事件（JSON/Avro），按 deviceId 作为 key 发 Kafka。避免“每设备一分区”，而是“按哈希范围/地域/组织分区”，分区数阶段性扩（如 24 → 48 → 96）。：Redis 是单线程处理命令的，大 key 或大批量数据一次取出会长时间占用 CPU，阻塞其他请求。拉全量数据要跨节点遍历。：一次性把很多数据打包返回，服务器需要序列化成 TCP 包，客户端要解包，容易卡顿甚至 OOM。：一次性拉取完全没问题，Redis 单线程响应极快，网络带宽也能支撑。
2025-08-22 07:36:59
1808
原创 分布式微服务系统架构第166集：华为经验汇总
集成了 Ribbon（负载均衡）和 Hystrix（容错降级，旧版），新版可配合 Spring Cloud LoadBalancer 和 Sentinel。docID/pos 用 gap（差分）+ 可变长（VarInt/VarByte/VByte）或 PForDelta、QMX 等压缩。，可以让你把应用和它的依赖打包在一个轻量级、可移植的容器里运行，避免“在我电脑上可以跑”的问题。必须与注册中心（Eureka / Nacos）里的服务名一致，且要启用负载均衡（默认开启）。
2025-08-18 06:56:45
1109
原创 分布式微服务系统架构第165集：阿里，字节，腾讯架构经验汇总
设备 ID 通过哈希（如 Murmur3）转为一个 Long 型 token，落在哪个 token 区间，就由那个节点负责存储。每个设备 ID 或主键，都会通过哈希函数（如 Murmur3）生成一个 Token（Long 类型的整数）。，经过哈希得到一个 token，它会落入某个范围，于是 Cassandra 就将该数据分配给对应的节点。来判断分布，而是直接用 token 落在哪个节点负责的 token 范围。对应的数据会存储在哪个节点（token 范围负责的节点）上。
2025-08-18 06:56:45
941
原创 分布式微服务系统架构第164集：架构懂了就来了解数据库存储扩展千亿读写
Vitess/TiDB/Citus 上线；：MySQL(分库分表/ Vitess) / PostgreSQL(Citus) / NewSQL（TiDB / CockroachDB / OceanBase）（TiCDC/Debezium）把交易变更送到 Kafka，再同步到下游（ES/ClickHouse/缓存）：ClickHouse / Pinot / Druid（列式 + 分区，近实时 OLAP）：TiCDC/Debezium → Kafka → ClickHouse/ES/缓存回填。
2025-08-11 00:01:10
1217
原创 分布式微服务系统架构第163集：哈罗电池设备Netty网关架构
网关宕机：不续租→TTL 到期（~180s）→映射消失→设备重连被 Nginx 分配到新网关→新网关用“接管 Lua”将 lease 版本+1 并写入。上报数据：网关解码→校验→异步写 Kafka（at-least-once），关键字段落地（如设备在线态、最近电压等可走 Redis/时序库）。：Prometheus 指标（连接数、心跳延迟、解码失败、写队列积压、指令RT/成功率）；：先查 Redis 查到网关IP→RPC/HTTP 到该网关内置“下发接口”→Channel 定位并写。：黑名单、频率限制；
2025-08-10 13:13:21
494
原创 分布式微服务系统架构第162集：如果是小米的过亿设备，如何搭建架构
新项目首选，线程安全，支持异步/响应式，Spring Boot 2.x 之后默认使用 Lettuce 代替 Jedis。优点：一个连接就能支持多线程，且异步性能好，特别适合高并发和 Spring WebFlux 这种响应式架构。监控：Prometheus + Grafana（曲线看连接数、堆、GC、CPU）：简单、老牌、容易上手，但线程安全差，需要连接池管理；：没有连接数/GC/CPU/Redis延迟监控，很难定位抖动。网关挂了，Nginx 会把连接迁移到其他网关，设备端会自动重连。
2025-08-10 13:13:21
1187
原创 分布式微服务系统架构第161集：过亿设备架构-AI生成架构图
业务若要下发，先查 Redis 看设备在哪台网关，再通过网关本地 ChannelManager 找 Channel 写回（或走 RPC/网关间转发）。：放行 7000（NLB→Nginx）、9000（Nginx→Netty）、Redis/Kafka 内网端口；netty/handler/BusinessDispatcherHandler.java（推送到 Kafka）NLB 健康后开始分流。、直连内存+堆外缓冲可到 10~15 万长连接/台（看内存/网卡/内核参数）。
2025-08-09 07:52:07
1319
原创 分布式微服务系统架构第160集：百万台设备Netty网关架构
网关宕机时，该设备的 Redis Key 不会续期，自动过期后，Nginx 会将连接路由到新的可用网关。实例，是 Netty 服务端启动的核心辅助类，用于配置服务器端的各项参数。这样才能转发原生 TCP 数据（Netty、JT808、MQTT 等）。：让同一个域名指向多台网关服务器（每台运行 Netty 网关服务）。模式支持 TCP 转发（Netty、MQTT、JT808）。统计当前连接数量，支持高并发下的线程安全自增/自减操作。，这是 Netty 为服务器端提供的异步非阻塞通道。
2025-08-08 07:53:55
1246
原创 MongoDB分片技术实现
MongoDB分片（Sharding）是MongoDB的水平扩展解决方案，通过将数据分布到多个分片（shard）上来处理大数据量和高吞吐量的需求。通过合理的设计和实施，MongoDB分片可以为应用提供优秀的水平扩展能力。MongoDB分片技术是处理大规模数据的重要解决方案。：合理规划Config Server、分片和mongos的部署。：选择合适的分片键是关键，需要平衡查询性能和数据分布。选择高基数、查询频繁的字段作为分片键。：尽量包含分片键以避免跨分片查询。MongoDB分片技术实现。
2025-08-02 15:55:27
481
原创 HBase分片技术实现
HBase是基于Hadoop的分布式、可扩展的NoSQL数据库，采用列族存储模型。HBase的分片机制通过Region自动分割和负载均衡实现水平扩展，支持PB级数据存储和高并发访问。在实际应用中，需要根据业务特点优化RowKey设计、表结构和分片策略，并建立完善的监控和运维体系。HBase分片技术通过Region自动分割和负载均衡实现了高可扩展性和高可用性。: 集群管理节点，负责Region分配和负载均衡。: Region根据大小自动分割，支持水平扩展。: 合理的RowKey设计是性能的关键。
2025-08-02 15:55:27
553
原创 Elasticsearch分片技术实现
Elasticsearch分片（Sharding）是其分布式架构的核心，通过将索引分割成多个分片来实现水平扩展。每个分片都是一个独立的Lucene索引，可以分布在集群的不同节点上。Elasticsearch分片技术是构建高性能、高可用搜索系统的关键。在实际应用中，需要根据业务特点调整分片策略，并建立完善的监控和运维体系。: 避免过度分片，通常每个节点1-3个分片。: 自动化索引的创建、滚动和删除。: 分片分布实现查询负载分散。: 根据数据增长预估分片数。: 监控分片在节点间的分布。
2025-08-02 15:55:27
462
原创 ClickHouse分片技术实现
ClickHouse是一个用于在线分析处理(OLAP)的列式数据库管理系统，具有极高的查询性能。ClickHouse的分片机制通过分布式表和本地表的组合实现水平扩展，支持PB级数据的实时分析。ClickHouse分片技术通过分布式表和本地表的组合实现了高性能的OLAP查询能力。在实际应用中，需要根据数据特点和查询模式优化表结构、分片策略和查询方式，并建立完善的监控和运维体系。**避免SELECT ***: 只查询需要的列。: 通过分片和副本实现水平扩展和高可用。: 数据分片，每个分片包含部分数据。
2025-08-02 15:55:27
422
原创 子网掩码是什么
子网掩码（Subnet Mask）是一个32位的二进制数，用于将IP地址分割成网络部分和主机部分，是网络通信中的重要概念。在实际工作中，掌握子网掩码的计算方法和应用场景，能够帮助我们更好地进行网络规划和故障排除。子网掩码的作用就是告诉计算机："这个IP地址的前面几位是网络地址，后面几位是主机地址"。/24网络：2^(32-24) - 2 = 254台主机。/25网络：2^(32-25) - 2 = 126台主机。/27网络：2^(32-27) - 2 = 30台主机。使用/24网络（254台主机）
2025-07-31 12:19:01
806
原创 分布式微服务系统架构第159集：高并发系统
它将整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。很显然嘛，你在每秒一次请求和每秒一万次请求，两种不同的场景下，分别做到毫秒级响应时间和五个九（99.999%）的可用性，无论是设计难度还是方案的复杂度，都不是一个级别的。缓存遍布在系统设计的每个角落，从操作系统到浏览器，从数据库到消息队列，任何略微复杂的服务和组件中，你都可以看到缓存的影子。
2025-07-16 07:17:11
697
原创 分布式微服务系统架构第158集：JavaPlus技术文档平台日更-JVM基础知识
Java虚拟机（Java Virtual Machine，JVM）是Java程序的运行环境，它是Java实现"一次编译，到处运行"的核心。JVM负责将Java字节码转换为特定平台的机器码，并提供内存管理、垃圾回收、安全检查等功能。JVM作为Java程序的运行环境，其深入理解对于Java开发者至关重要。通过深入理解JVM原理和实践经验的积累，能够更好地开发高性能、稳定的Java应用程序。垃圾回收是JVM自动管理内存的机制，负责回收不再使用的对象所占用的内存空间。
2025-07-05 16:09:51
756
原创 分布式微服务系统架构第157集：JavaPlus技术文档平台日更-Java多线程编程技巧
通过掌握这些Java多线程编程技巧，可以编写出更加高效、安全和可维护的并发程序。记住，多线程编程需要谨慎对待，充分的测试和监控是确保程序正确性的关键。IO密集型：线程数 = CPU核心数 × (1 + IO等待时间/CPU计算时间)选择合适的同步工具（synchronized、Lock、原子类等）性能分析工具（JProfiler、Async Profiler等）CPU密集型：线程数 = CPU核心数 + 1。使用线程本地变量（ThreadLocal）线程和线程池使用有意义的名称。
2025-07-05 16:09:51
767
原创 分布式微服务系统架构第155集：JavaPlus技术文档平台日更-Java线程池实现原理
线程池（Thread Pool）是一种多线程处理形式，预先创建若干个线程，这些线程在没有任务处理时处于等待状态，当有任务来临时分配给其中的一个线程来处理，当处理完后又回到等待状态等待下一个任务。通过深入理解线程池的实现原理和最佳实践，可以更好地利用线程池提升应用性能和稳定性。：重写afterExecute方法处理任务执行异常。：正确配置核心线程数、最大线程数、队列大小等参数。：实时监控线程池的运行状态和性能指标。：确保线程池正确关闭，避免资源泄漏。：确保应用关闭时正确关闭线程池。
2025-07-05 16:09:51
938
CountTime-AndroidStudio项目制作倒计时模块
2018-04-03
book微信小程序
2018-06-22
Android---UI篇---Menu（菜单）
2017-11-27
如何实现点击关于按钮，获得APP的版本号，APP的签名信息，APP的权限申请信息
2017-11-06
TA创建的收藏夹 TA关注的收藏夹
TA关注的人