FFFL

what a terrible repo!!!!

After https://github.com/zellij-org/zellij/pull/1644 this have been solved, I think this issue can be closed and shouldn't be opened in the first place :-(

此任务已被 @Winson-Huang 认领，欢迎交流。

# 整体思路 Arthas 的 `profiler` 命令是在 `ProfilerCommand` 类中通过调用 async-profiler 的 Java API（位于 `one.profiler` 包中）实现的。目前两者在使用上有两点主要差异。首先，一般来说 Arthas 在启动时指定目标进程，在 CLI 内执行的命令均作用于指定的进程，命令中不必指定进程标识，但对于 async-profiler，其目前最新正式版 v2.9 的 CLI（在 `profiler.sh` 脚本中实现）仍需要每次执行命令时指定进程标识。此外，Arthas 的 `profiler` 命令具体选项也与 async-profiler CLI 的选项不完全一致。...

目前大部分功能实际上在我的本地仓库已经完成了，我的计划是按 action 逐个提交 PR 进行讨论和细化。

@hengyunabc 关于 `framebuf` 选项，目前 Arthas 中仍存在，但 async-profiler 2.9 版本已经移除了此选项，需要确定在 Arthas 中如何处理。 首先，此选项大概率不是 issue #2625 中提到的无法生成火焰图的原因，我的测试结果和您提到的 comment 一样，火焰图可以正常生成。 然后，此选项确实会导致出现没有用处的 warning 信息，要消除此信息，只要不将 framebuf 参数加入 JVM TI 字符串即可。 最简单的方式是直接将此选项和相关变量直接移除，但这会破坏 Arthas 的向后兼容。第二种方式是让 Arthas 仍接收此选项，但不传递给...

其实我的意思是，如果直接去掉此选项，那么使用旧版本 arthas 时的那些带有 framebuf 选项的命令就不适用与新版本 arthas 了。不过如果 arthas 绝大部分情况是用手动输入命令进行控制，而没有 arthas 命令脚本这种输入形式的话，是不是不太需要考虑这种向后兼容性？

Arthas 的文档中没有明确说这一点，是不是 Arthas 本身没有命令脚本这种输入形式？

## 关于 fdtransfer 选项的讨论 在 shell 脚本的 start/resume action（[L347](https://github.com/async-profiler/async-profiler/blob/32601bccd9e49adda9510a2ed79d142ac6ef0ff9/profiler.sh#L347)）处理流程中，在启动 profiler 之前会根据 `--fdtransfer` 选项决定是否启动 fdtransfer 工具。该工具用于在低权限环境（容器环境）下响应 perf 请求，但 Java API 中未提供启动该工具的方法，Arthas 中未实现此选项也未包含 fdtransfer 工具。是否要实现该选项，以及如何实现该选项，**有待进一步讨论**。 根据 [Discussion](https://github.com/async-profiler/async-profiler/discussions/796)，无法从待分析的 Java 进程本身启动该工具，也就是不能利用织入的代码启动该工具，一种可行的办法是 Arthas 进程本身使用高权限启动，并启动 fdtransfer...

## 关于 collect action 的讨论 在 profiler.sh 脚本中，[L233](https://github.com/async-profiler/async-profiler/blob/32601bccd9e49adda9510a2ed79d142ac6ef0ff9/profiler.sh#L233) --timeout --loop 这两个选项的设计有些奇怪。timeout 在行为上与 duration 有些类似，功能上也有些重复。loop 的作用是让 profiler 持续执行，但每隔一段时间就将【这一段时间内】的分析结果输出到文件。在 async-profiler 中，PARAMS 变量仅用于 start、resume、check、collect 这 4 个 ACTION，DURATION 变量仅用于 collect。并且当 ACTION 为 collect...