wppwpp1
码龄15年
求更新 关注
提问 私信
  • 博客:323,024
    社区:501
    323,525
    总访问量
  • 195
    原创
  • 217
    粉丝
  • 145
    关注
IP属地以运营商信息为准,境内显示到省(区、市),境外显示到国家(地区)
IP 属地:上海市
加入CSDN时间: 2010-08-08
博客简介:

wppwpp1的专栏

查看详细资料
个人成就
  • 获得253次点赞
  • 内容获得55次评论
  • 获得491次收藏
  • 代码片获得593次分享
  • 博客总排名1,374,969名
创作历程
  • 16篇
    2024年
  • 28篇
    2023年
  • 27篇
    2022年
  • 47篇
    2021年
  • 78篇
    2020年
  • 13篇
    2019年
  • 1篇
    2011年
成就勋章
TA的专栏
  • Redis
    3篇
  • java
    39篇
  • spring boot
    8篇
  • 实时数仓
    2篇
  • flink
    69篇
  • idea
    3篇
  • leetcode
  • kafka
    5篇
  • mac
    2篇
  • spark
    7篇
  • maven
    4篇
  • UDF
    5篇
  • calcite
    1篇
  • hadoop
    6篇
  • doris
    2篇
  • clickhouse
    12篇
  • yarn
    3篇
  • mysql
    1篇
  • python
  • HQL
    4篇
  • hive
    6篇
  • spark Streaming
    6篇
  • springBoot
    2篇
  • shell
    1篇
  • scala
    1篇
  • docker
    2篇

TA关注的专栏 2

TA关注的收藏夹 0

TA关注的社区 0

TA参与的活动 0

创作活动更多

AI 镜像开发实战征文活动

随着人工智能技术的飞速发展,AI 镜像开发逐渐成为技术领域的热点之一。Stable Diffusion 3.5 FP8 作为强大的文生图模型,为开发者提供了更高效的图像生成解决方案。为了推动 AI 镜像开发技术的交流与创新,我们特此发起本次征文活动,诚邀广大开发者分享在 Stable Diffusion 3.5 FP8 文生图方向的实战经验和创新应用 本次征文活动鼓励开发者围绕 Stable Diffusion 3.5 FP8 文生图方向,分享以下方面的内容: 1. 技术实践与优化 - Stable Diffusion 3.5 FP8 模型架构解析与优化技巧 - 文生图生成效果的提升方法与技巧 - 模型部署与加速策略,例如使用 Hugging Face、Diffusers 等工具 - 针对特定场景(例如二次元、写实风)的模型微调与定制化开发 2. 应用场景探索 - Stable Diffusion 3.5 FP8 在不同领域的应用案例分享,例如游戏设计、广告创意、艺术创作等 - 利用 Stable Diffusion 3.5 FP8 实现图像编辑、图像修复、图像增强等功能的探索 - 结合其他 AI 技术(例如 NLP、语音识别)构建更强大的应用 3. 创新应用与思考 - 基于 Stable Diffusion 3.5 FP8 的创新应用场景设计 - AI 镜像开发的未来发展方向的思考与展望 - 对 AI 镜像开发伦理、安全等问题的探讨

28人参与 去参加
  • 最近
  • 文章
  • 专栏
  • 代码仓
  • 资源
  • 收藏
  • 关注/订阅/互动
更多
  • 最近

  • 文章

  • 专栏

  • 代码仓

  • 资源

  • 收藏

  • 关注/订阅/互动

  • 社区

  • 帖子

  • 问答

  • 课程

  • 视频

搜索 取消

动态代理相关知识点

【代码】动态代理相关知识点。
原创
博文更新于 2024.09.19 ·
355 阅读 ·
3 点赞 ·
0 评论 ·
0 收藏

JVM运行机制深入分析

发布资源 2019.04.01 ·
pptx

ZGC的流程图

•转发表记录了对象从旧位置到新位置的映射关系,实现类似一个hash表,key是旧分区的位置,value是新分区的位置,此时当访问旧位置的对象时,通过转发表可以获取新位置。通过读屏障,ZGC能够在读取对象引用时,将访问重定向到新位置,以确保对象的访问仍然有效。迁移根节点直接引用的对象到新分区,这个阶段需要停顿所有的应用线程(STW),但由于只迁移根节点直接引用的对象,所以停顿时间很短。刚好下一个GC周期也要进行扫描标记,可以利用扫描标记的时间,同时把对象引用修正指向到新分区,以此提升效率,减少停顿时间。
原创
博文更新于 2024.07.12 ·
1031 阅读 ·
5 点赞 ·
0 评论 ·
7 收藏

ZGC在三色指针中的应用

在转移阶段,ZGC是按照页面进行部分内存垃圾回收的,也就是说当对象所在的页面需要回收时,页面里面的对象需要被转移,如果页面不需要转移,页面里面的对象也就不需要转移。ZGC初始化之后,整个内存空间的地址视图被设置为Remapped,当进入标记阶段时的视图转变为Marked0(也称为M0)或者Marked1(也称为M1),从标记阶段结束进入转移阶段时的视图再次设置为Remapped。如果应用程序线程访问在对象活跃信息表中,且视图为M0,说明对象是标记阶段标记的活跃对象,所以需要转移对象。
原创
博文更新于 2024.07.08 ·
1391 阅读 ·
14 点赞 ·
0 评论 ·
12 收藏

jdk21颜色指针研究

这种技术的目的是在对象移动时,通过修改指针本身而不是对象的引用关系,来维护正确的引用关系,从而避免了对引用对象的访问和修改。在自愈指针技术中,指针的高位(通常是一些特定的位或字节)被用来存储额外的信息,例如对象的新地址、标记信息等。这样一来,垃圾标记阶段遍历的不再是对象图来标记垃圾,而是通过遍历“引用图”来标记垃圾,引用的对象便是堆中的对象。通过这四个标志位,JVM可以直接从对象的指针上获取关键的状态信息,而无需访问对象本身的其他属性,这种直接的标志位设计有助于提高垃圾收集的效率和性能。
原创
博文更新于 2024.07.08 ·
1046 阅读 ·
29 点赞 ·
0 评论 ·
8 收藏

java到底是值传递还是引用传递

1、一定是值传递,给你的表象也有引用传递是因为对象传递的引用地址,我们在堆里更改了对象的属性值,但是地址没有变更,所以是值传递,可以参考方法的堆栈。
原创
博文更新于 2024.07.03 ·
262 阅读 ·
3 点赞 ·
0 评论 ·
0 收藏

JAVA ZGC相关GC日志详情分析

记录了 ZGC 各个阶段的耗时,其中 "Pause" 与 "Concurrent" 分别标识了 STW 阶段与并发阶段。其中 "gc*" 意为打印所有 tag 中以 "gc" 开头的日志,"gc.log" 为日志存储路径。第 1 行标志了一次 GC 的开始,是进程启动后的第 100 次(从 0 开始计数)GC,触发原因为 "Timer"。"Final":终结引用(FinalReference)。下面以 AutoMQ 在实际运行时的一次 GC 为例,按照不同的 log tag,解释 ZGC 日志的含义。
原创
博文更新于 2024.07.03 ·
1852 阅读 ·
13 点赞 ·
0 评论 ·
22 收藏

NativeMemoryTracking查看java内存信息

默认该功能是禁用的,因为会损失5-10%的性能。
原创
博文更新于 2024.07.02 ·
851 阅读 ·
2 点赞 ·
0 评论 ·
0 收藏

ZGC垃圾收集的主要流程

GC Roots(例如,线程栈中引用的对象,静态变量等)为每次标记的起点,所有被 GC Roots 引用的对象都应被认为是存活的;与此同时,发现对象 2 引用了对象 5,而对象 5 的颜色是“坏的”(对象 5 的实际颜色 Marked0 与期望颜色 Remapped 不符),会基于转发表,将对象 5 的地址重映射对象 5'。值得注意的是,此时对象 2(对象 4')中记录的对象 5(对象 7)的地址仍为迁移前的地址,指针的颜色也仍为标记时的颜色 Marked0。此外,还需要将上一次 GC 的转发表删除。
原创
博文更新于 2024.06.26 ·
854 阅读 ·
13 点赞 ·
0 评论 ·
9 收藏

ZGC垃圾收集器介绍

相比G1、Shenandoah等先进的垃圾收集器,ZGC在实现细节上做了一些不同的权衡选择。譬如G1需要通过写屏障来维护记忆集,才能处理跨代指针,得以实现Region的增量回收。记忆集要占用大量的内存空间,写屏障也对正常程序运行造成额外负担,这些都是权衡选择的代价。
原创
博文更新于 2024.06.26 ·
1481 阅读 ·
32 点赞 ·
0 评论 ·
24 收藏

jstack的火焰图使用说明

2、jstack的文件分析网站,可以关注cpu消耗比较高的线程和火焰图。1、jstack的官方文档说明。
原创
博文更新于 2024.06.25 ·
473 阅读 ·
1 点赞 ·
0 评论 ·
0 收藏

GC Roots相关数据分析和示例解析

在Java虚拟机(JVM)中,垃圾收集器(Garbage Collector, GC)的GC Roots是一组对象,这些对象作为起始点,用于确定哪些对象仍然可达(即“存活”)以及哪些对象不再可达(即“垃圾”)。当进行垃圾收集时,GC会从这些GC Roots开始,遍历整个对象图,标记所有可达的对象,并回收所有不可达的对象。请注意,GC Roots的值并不是固定不变的,它们随着程序的执行而动态变化。当一个新的线程被创建时,它的栈帧中的对象会成为新的GC Roots;
原创
博文更新于 2024.06.24 ·
439 阅读 ·
5 点赞 ·
0 评论 ·
3 收藏

查看cpu异常的shell命令

【代码】查看cpu异常的shell命令。
原创
博文更新于 2024.06.21 ·
292 阅读 ·
2 点赞 ·
0 评论 ·
0 收藏

springboot应用cpu飙升的原因排除

1、通过top或者jps命令查到是那个java进程, top可以看全局那个进程耗cpu,而jps则默认是java最耗cpu的,比如找到进程是196。5、发现196进程里的线程id:590是最耗cpu的,可以使用linux命令直接kill掉,杀死线程命令是 两个 --4、查询jstack.log相关的 ,pid为 590的值,可以查看堆栈信息,找到具体的业务代码。2、根据第一步获取的进程号,查询进程里那个线程最占用cpu,发现590消耗最多。1.1 top (推荐)或者jps命令均可。
原创
博文更新于 2024.06.20 ·
2444 阅读 ·
1 点赞 ·
0 评论 ·
4 收藏

关于springboot一个接口请求后,主动取消后,后端是否还在跑

1、最近在思考一个问题,如果一个springboot的请求的接口比较耗时,中途中断该请求后,则后端服务是否会终止该线程的处理,于是写了一个demo。4、发现即使取消请求后,springboot后端还是会进行业务处理,不会自动终止的。
原创
博文更新于 2024.03.06 ·
2986 阅读 ·
3 点赞 ·
0 评论 ·
0 收藏

java的safepoint介绍

可以参考下面wiki,讲的很详细。
原创
博文更新于 2024.01.25 ·
665 阅读 ·
8 点赞 ·
0 评论 ·
4 收藏

Maven类包冲突终极三大解决技巧 mvn dependency:tree

(这一步非常重要哦,经常项目组pom.xml是相同的,但是就是有些人可以运行,有些人不能运行,俗称人品问题,其实都是IDE的缓存造成的了。这里有一个需要特别注意的,即B和C同时依赖于X,假设B依赖于X的1.0版本,而C依赖于X的2.0版本,A究竟依赖于X的1.0还是2.0版本呢?A依赖于B及C,而B又依赖于X、Y,而C依赖于X、M,则A除引B及C的依赖包下,还会引入X,Y,M的依赖包(一般情况下了,是把照妖照,pom.xml用它照照,所有传递性依赖都将无处遁形,并且会以层级树方式展现,非常直观。
原创
博文更新于 2024.01.09 ·
2093 阅读 ·
22 点赞 ·
0 评论 ·
29 收藏

Redis遇到过的问题 (Could not get a resource from the pool )

其中查看所有连接的展示的列表内容我在下方标出,注意看下idle这个字段,代表的空闲时间,单位是秒,这时可以看到idle的时间非常长,所以我这边确定程序获取获取大量的redis连接资源并且没有释放。否则,断开与 Redis 的连接。需要注意的是redisTemplate使用的是自动管理连接池,按道理来说调用完之后会自动释放连接,但是当redis开启了事务的时候,就需要手动释放连接,所以解决方案有两种。这么常用的方法,基于习惯,Java 在 jdk1.7 之后为我们提供了一个很好的方法。
原创
博文更新于 2023.12.25 ·
2413 阅读 ·
11 点赞 ·
0 评论 ·
11 收藏

jedisCluster模式下使用scan命令来删除指定前缀的字符串

之前搜了网上很多文章,发现jedisCluster.getClusterNodes()在jedis的4.x版本获取的对象Map,而不是Map。针对这个情况进行代码改造。因业务需要,需要对指定redis的前缀批量删除,如果直接使用keys 命令在数据量比较大的情况下会导致redis集群崩溃或者业务hang住。利用scan通过分页方式来拿到指定的key前缀,在进行相关数据的删除。来获取jedisNode客户段,具体代码如下。
原创
博文更新于 2023.12.21 ·
1549 阅读 ·
8 点赞 ·
0 评论 ·
8 收藏

common-pool的GenericObjectPool源码创建borrowObject方法研读

对象池主要管理对象的池,包含借用,归还,添加对象,校验对象是否有效等管理功能。
原创
博文更新于 2023.12.21 ·
607 阅读 ·
7 点赞 ·
0 评论 ·
6 收藏
加载更多