fix: agent - Fix proc-events high CPU on proc-info eviction

[yinjiping]

Problem

When a process exited or executed a new image, proc-events removed its symbolizer_proc_info from the hash and waited for all outstanding references to be released:

AO_DEC(&p->use);

while (AO_GET(&p->use) != 0)
    CLIB_PAUSE();

free_proc_cache(p);

If a Java symbol task or another reader failed to release its reference, p->use never reached zero. The proc-events thread then spun indefinitely, consuming an entire CPU core and preventing subsequent exec/exit events from being processed.

Java symbol task                 proc-events
       │                              │
       ├─ p->use++                    │
       ├─ waits for symbol refresh    │
       ├─ fails to release reference  │
       │                              ├─ removes p from hash
       │                              ├─ drops the base reference
       │                              └─ while (p->use != 0)
       │                                      │
       │                                      └─ spins forever

1. Make Java Symbol Refresh Bounded and Wakeable

The Java symbol refresh path was updated so it can no longer retain a proc-info reference indefinitely.

Changes include:

• Replaced the unbounded pthread_cond_wait() with pthread_cond_timedwait().
• Added a 10-second refresh timeout:

#define JAVA_SYMS_REFRESH_TIMEOUT_SECS 10

• On timeout, clear need_refresh, set the update status to failure, and return so the caller can release p->use.
• Protect setting, checking, clearing, waiting, and signaling need_refresh with the same task->mutex to prevent lost wakeups.
• When the collector exits, mark the task as stopped and broadcast the condition variable so all waiters wake immediately.

2. Protect Java Symbol Task Lifetime

The Java task itself could previously be freed while another thread was still accessing it.

The task now contains:

ref_count
stopped

The creator, worker, and refresh waiter hold their own references. The task is destroyed only after the final reference is released.

Additional thread-pool fixes include:

• Roll back queued tasks when realloc() or pthread_create() fails.
• Correctly check pthread_create() using ret != 0.
• Avoid publishing invalid worker slots.
• Retain the task while collector setup is still using it.
• Prevent dangling queue entries.
• Prevent map/log sockets from being closed twice.

Relevant commits:

df24172 fix: agent - Fix proc-events high CPU on proc-info eviction
8cdc452 fix: synchronize Java symbol refresh requests
9abed00 fix: handle pthread_create errors correctly
5bada36 fix: retain Java symbol task during collector setup

3. Protect hash_search → use++ Reference Acquisition

A separate UAF window existed between finding a proc-info pointer and incrementing its reference count:

reader                         writer/proc-events
  │                                    │
  ├─ hash_search returns p             │
  ├─ descheduled                       │
  │                                    ├─ removes p from hash
  │                                    ├─ use becomes zero
  │                                    └─ frees p
  │
  └─ AO_INC(&p->use)  ← UAF

The lookup path now uses cache-line-separated per-thread reader slots:

reader slot active++
    -> hash_search(pid)
    -> p->use++
reader slot active--

Writers serialize hash search/delete operations and wait for all active reference-acquisition sections to finish after removing an entry:

writer lock
    -> hash search
    -> hash delete
writer unlock
    -> synchronize_proc_cache_ref_acquirers()
    -> transfer or release the hash-owned reference

This protects only the short hash_search → use++ window. The caller’s later access remains protected by p->use.

Commit:

33b2fbe fix: protect proc cache reference acquisition

4. Remove Busy-Waiting from Proc-Info Eviction

The fundamental high-CPU fix was to stop waiting synchronously for p->use to reach zero.

The old behavior:

while (AO_GET(&p->use) != 0)
    CLIB_PAUSE();

was replaced with deferred reclamation:

if (AO_SUB_F(&p->use, 1) == 0)
    free_proc_cache(p);
else
    add p to retired_proc_caches;

The proc-events thread now continues processing other events immediately.

A reaper periodically scans the retired list:

use == 0: remove and free
use > 0:  leave in the list and check again later

Expensive symbol-cache destruction is performed after releasing the retired-list lock.

reader/Java task                 proc-events
       │                              │
       ├─ holds p->use                ├─ removes p from hash
       │                              ├─ drops the base reference
       │                              ├─ sees use > 0
       │                              ├─ adds p to retired list
       │                              └─ continues processing events
       │
       └─ p->use--                    later reaper
                                          ├─ sees use == 0
                                          └─ frees p

Even if a future reference is retained indefinitely, proc-events will no longer spin or block.

Commit:

8e2cf07 fix: defer proc cache reclamation

5. Record Why a Reference Was Acquired

A use_reason marker was added to symbolizer_proc_info to help diagnose long-lived references.

The currently recorded reasons are:

PROC_USE_INC_REASON_UNKNOWN
PROC_USE_INC_REASON_HASH_QUERY
PROC_USE_INC_REASON_JAVA_TAST

The marker records the most recent important reference-increment reason. It does not maintain a separate reference count for each reason.

Commit:

5a05cd2 feat: record proc cache reference reason

6. Add Retired Proc-Cache Diagnostics

The retired list now has:

• A dedicated mutex.
• A monotonic retirement timestamp.
• Current retired-object count.
• Oldest waiting time.
• Accounted memory estimates.
• Process start time and symbol-cache state.

The following command was added:

deepflow-ebpfctl proc-cache-reclaim show --older-than 60

It reports summary fields such as:

active_count
retired_count
total_count
total_limit
usage
admission_paused
rejected_total
reclaimed_total
oldest_wait
overdue_count
matched_count
returned_count
truncated

Per-process details include:

PID
COMM
USE
WAIT(s)
START_TIME
MEMORY
SYMCACHE
LAST_INC_REASON

At most 1,024 detail records are returned per request, while summary counters still cover the complete retired list.

Commit:

de07b62 feat: expose proc cache reclamation diagnostics

Remote execution support was added separately in deepflow-core:

c2408af feat: expose proc cache diagnostics via remote exec

7. Bound Proc-Cache Memory Growth

Deferred reclamation prevents high CPU, but a permanently retained reference could still cause retired objects to accumulate. A configurable total object limit was therefore added:

inputs:
  ebpf:
    tunning:
      proc_cache_max_entries: 65536

Configuration:

Minimum:  1,024
Default: 65,536
Maximum: 262,144
Unit:     entries

The limit covers every allocated but not yet freed proc-cache object:

total_count =
    RESERVED
  + ACTIVE
  + IN_FLIGHT
  + RETIRED

A capacity slot is reserved before allocation using CAS. It is returned on every initialization failure or after final destruction in free_proc_cache().

When the limit is reached:

• New proc-cache creation is rejected.
• Existing lookups continue.
• Hash deletion continues.
• Ring processing continues.
• Retired-object reclamation continues.
• Target processes are unaffected.
• Creation resumes automatically after the total count falls below the limit.

The limit applies on Agent startup and supports runtime hot updates.

Commits:

43496df feat: bound proc cache memory growth
f12aadd docs: clarify proc cache capacity accounting

8. Preserve Ownership When Ring Enqueue Fails

After a proc-info entry leaves the hash, ownership is normally transferred to proc_event_ring.

Previously, if event allocation or ring enqueue failed, the object could be left without an owner:

not in hash
not in ring
not in retired list

The failure path now retains ownership locally:

if (add_proc_ev_info_to_ring(type, &kv) != 0 &&
    kv.v.proc_info_p != 0)
    free_symbolizer_cache_kvp(&kv);

The object is then either:

• Freed immediately when use == 0, or
• Added to the retired list when references remain.

This prevents leaks of the proc-info object, its symbol cache, and its capacity slot.

9. Add Capacity Metrics and Rate-Limited Logging

Runtime metrics include:

proc_cache_active_count
proc_cache_retired_count
proc_cache_total_count
proc_cache_total_limit
proc_cache_rejected_total
proc_cache_reclaimed_total
proc_cache_oldest_wait_secs

Capacity logging behavior is:

First time the limit is reached:       immediate WARNING
Continued capacity pressure:           at most one WARNING every two hours
Capacity recovery:                     immediate INFO
Limit reached again after recovery:    immediate WARNING

The timestamps use CLOCK_MONOTONIC, so system clock adjustments do not affect rate limiting.

Repeated warnings are event-driven: if no creation, release, or configuration event occurs, only the initial warning is guaranteed.

Performance Impact

The capacity work does not add a global capacity lock, capacity CAS, retired-list lock, or logging check to normal proc-info hash lookups.

New operations occur only during:

• Proc-cache creation.
• Creation failure rollback.
• Final object destruction.
• Configuration updates.
• Diagnostics and metrics collection.

The lookup path retains only the short per-thread reader-slot protection needed to make hash_search → use++ safe.

Final Protection Model

The final implementation provides three layers of protection:

Layer 1: Bounded Java refresh and safe task lifetime
         Prevent references from being retained indefinitely.

Layer 2: Safe reference acquisition and deferred reclamation
         Prevent UAF and ensure proc-events never busy-waits.

Layer 3: Global proc-cache object limit
         Prevent unbounded memory growth even if a reference is permanently leaked.

The resulting behavior guarantees that:

• proc-events no longer spins while waiting for p->use.
• The hash_search → use++ window cannot access freed memory.
• Java refresh waiters cannot block forever or access a freed task.
• Referenced objects are safely moved to the retired list.
• Long-lived references are observable through wait time and reason.
• Ring failures do not lose object ownership.
• Total proc-cache object growth is bounded.
• Normal proc-info lookup remains free of new global capacity locks.

Branches involved

• v6.6 (fix branch on the authoritative host); merge into later releases as planned.

Checklist

• Dependency update needed (no)
• Common problem (bounded wait / reference counting reusable for other tasks in the same pool)
• Compiles (gcc -fsyntax-only SYNTAX_OK)
• Unit tests pass (to run on the authoritative host per the verification plan)

This PR is for:

[kylewanginchina]

@claude review一下当前PR中的代码修改

[claude]

Claude encountered an error after 3m 19s —— View job

---

I'll analyze this and get back to you.

[kylewanginchina]

必须修改的问题

1. 修复 worker 获取错误 thread_index 的并发问题

位置：

• worker_thread()
• thread_pool_add_task()

当前通过共享变量传递新 worker 的索引：

pool->thread_index = pool->thread_count;
pthread_create(&thread, NULL, &worker_thread, pool);

worker 启动后再读取：

int thread_idx = pool->thread_index;

如果短时间连续创建两个 worker，第一个 worker 可能在线程启动较晚时读到第二个 worker 的 index，随后因为线程 ID 不匹配而退出：

if (pool->threads[thread_idx].thread != thread)
    pthread_exit(NULL);

可能造成：

• thread_count 仍包含已经退出的 worker；
• Java symbol task 永久留在 pending queue；
• collector 永远不启动；
• task/socket/refcount 长期不释放。

必须修改的原因

这是实际的任务永久卡住风险，而且当前 MR 正在修改同一段线程池创建逻辑。若不处理，MR 虽然修复了一类永久等待，但仍可能通过另一条路径制造永久 pending。

建议修改

不要使用共享的 pool->thread_index 传递 index。可以：

• 给每个 worker 传独立的 {pool, index} 启动参数；或
• worker 获取 pool->lock 后，通过 pthread_equal() 查找自己的 slot。

---

2. 修正 pthread_cond_timedwait() 的超时判断和 deadline

位置：

update_java_symbol_file()

当前实现：

while (task->need_refresh) {
    struct timespec ts;
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_sec += JAVA_SYMS_REFRESH_TIMEOUT_SECS;

    refresh_rc =
        pthread_cond_timedwait(&task->cond, &task->mutex, &ts);

    if (refresh_rc == ETIMEDOUT) {
        task->need_refresh = false;
        task->update_status = -1;
        break;
    }
}

这里有两个相关问题，应当合并成一个 Review 意见。

2.1 timeout 后没有重新检查 predicate

刷新完成和 timeout 可能同时发生。collector 可能已经执行：

task->update_status = 0;
task->need_refresh = false;
pthread_cond_signal(&task->cond);

但 pthread_cond_timedwait() 仍可能在边界条件下返回 ETIMEDOUT。当前代码会直接把成功结果覆盖成：

task->update_status = -1;

应该先检查：

if (!task->need_refresh)
    break;

只有 predicate 仍然为 true，才认定刷新超时。

2.2 deadline 不应在循环内重新计算

当前每次 spurious wakeup 都会重新获得 10 秒等待时间，因此不能严格保证整个调用最多等待 10 秒。

deadline 应在进入循环前计算一次，后续重复使用。

建议结构

struct timespec deadline;
clock_gettime(CLOCK_REALTIME, &deadline);
deadline.tv_sec += JAVA_SYMS_REFRESH_TIMEOUT_SECS;

while (task->need_refresh && !task->stopped) {
    int rc = pthread_cond_timedwait(
        &task->cond, &task->mutex, &deadline);

    /* 先检查业务条件，处理 signal/timeout 边界竞争。 */
    if (!task->need_refresh || task->stopped)
        break;

    if (rc != 0) {
        task->need_refresh = false;
        task->update_status = -1;
        break;
    }
}

更理想的是使用 CLOCK_MONOTONIC，但如果本 MR 希望控制范围，至少必须做到：

• deadline 只计算一次；
• timedwait 返回后先检查 predicate；
• 处理所有非零返回值。

必须修改的原因

“保证 Java symbol update 在有限时间内返回”是本 MR 的核心目标。如果 deadline 可以反复延长，或者成功结果会被 timeout 覆盖，说明核心等待逻辑还不完整。

---

合入前置条件

3. Rebase 最新 v6.6 并正确解决冲突

当前 PR 与 v6.6 存在冲突，相关 verify checks 也因此没有运行。

最新 v6.6 中已经存在大量 Java attach preflight 逻辑，而 MR 当前 head 中没有这些代码。解决冲突时必须保留：

• JVM 类型和版本检查；
• Java 8 安全版本限制；
• DisableAttachMechanism 检查；
• PID reuse 检查；
• namespace/version helper；
• preflight timeout 等逻辑。

这不需要写成一条具体的代码 Review comment，但它是合入的必要前提。冲突解决后需要重新看最终 diff。

---

不作为本 MR 阻塞项的问题

下面这些可以不要求当前 MR 修改：

proc-events 最多仍可能忙等 10 秒

while (AO_GET(&p->use) != 0)
    CLIB_PAUSE();

它确实意味着异常时仍可能短时间高 CPU，但本 MR 的核心价值是把“永久忙等”变成“有界等待”。如果团队接受这一行为，可以后续单独优化，不阻塞本 MR。

pthread_detach() 使用 errno 打印错误

这是错误日志准确性问题：

strerror(errno)

应该使用 pthread_detach() 的返回值，但不是核心稳定性问题，可以顺手改，也可以后续处理。

refcount assert、mutex/cond destroy

属于健壮性和代码规范优化，不是当前已确认的功能阻塞项。

正常刷新使用 broadcast

当前 Java symbol update 是单线程消费，通常只有一个 waiter，因此不要求本 MR 必须从 signal 改成 broadcast。

[yinjiping]

总结：proc-events 高 CPU 修复及后续加固

一、原始问题

进程退出或 exec 后，proc-events 会从 Proc Cache hash 中删除 p，然后释放 hash 持有的基础引用：

AO_DEC(&p->use);

while (AO_GET(&p->use) != 0)
    CLIB_PAUSE();

free_proc_cache(p);

如果 Java symbol task 或其他查询长期没有归还引用：

p->use 永远大于 0

proc-events 就会一直执行忙等：

while + CLIB_PAUSE

结果是：

• proc-events 长期占用一个 CPU。
• 后续 exec/exit 事件不能处理。
• Proc Cache 无法释放。
• 可能进一步积累内存。

原始时序：

Java symbol task             proc-events
       │                          │
       ├─ p->use++                │
       ├─ 等待 symbol refresh     │
       ├─ 异常后没有归还引用      │
       │                          ├─ 从 hash 删除 p
       │                          ├─ 基础引用 use--
       │                          └─ while (use != 0)
       │                                  │
       │                                  └─ 永久忙等，CPU 100%

---

二、修复 Java symbol 引用长期不归还

相关提交：

df24172 fix: agent - Fix proc-events high CPU on proc-info eviction
8cdc452 fix: synchronize Java symbol refresh requests
9abed00 fix: handle pthread_create errors correctly
5bada36 fix: retain Java symbol task during collector setup

主要修改位于 jvm_symbol_collect.c。

1. Java refresh 等待增加 10 秒超时

原来的无限等待：

pthread_cond_wait();

改成：

pthread_cond_timedwait();

最大等待：

#define JAVA_SYMS_REFRESH_TIMEOUT_SECS 10

超时后：

• 清除 need_refresh。
• 设置更新失败状态。
• 返回调用者。
• Java symbol 线程能够执行 p->use--。

2. 修复 condition variable 丢失唤醒

以下操作统一由 task->mutex 保护：

设置 need_refresh
检查 need_refresh
清除 need_refresh
等待 condition
发送 condition signal

避免请求线程刚设置 refresh、还没进入等待时，collector 已经完成 signal，导致请求线程永久睡眠。

3. collector 退出时唤醒等待者

collector 异常退出时设置：

task->stopped = true;
task->need_refresh = false;
task->update_status = -1;
pthread_cond_broadcast(&task->cond);

等待线程能够立即退出，不必永久等待已经消失的 collector。

4. Java task 增加引用计数

为 symbol_collect_task_t 增加：

ref_count
stopped

creator、worker 和 refresh waiter 分别持有引用，最后一个引用释放时才销毁 task，避免：

worker 释放 task
refresh waiter 继续访问 task
        ↓
       UAF

5. 修复线程池失败路径

补充处理：

• realloc() 失败后撤销已入队任务。
• 正确判断 pthread_create() 返回值是 != 0，不是 < 0。
• pthread_create() 失败后回滚队列计数。
• 避免任务留在队列中但已经被释放。
• 避免 map/log socket 被重复关闭。
• collector 初始化期间由 creator 引用保护 task。

---

三、修复 hash_search → use++ 之间的 UAF

提交：

33b2fbe fix: protect proc cache reference acquisition

原来的竞态：

reader                       writer/proc-events
  │                                  │
  ├─ hash_search 得到 p              │
  ├─ 被调度出去                      │
  │                                  ├─ 从 hash 删除 p
  │                                  ├─ use -> 0
  │                                  └─ free(p)
  │
  └─ p->use++  ← p 已释放，UAF

修复方式是在 find_proc_info_and_get_ref() 中使用 cache-line 分离的 per-thread reader slot：

reader slot active++
    -> hash_search
    -> p->use++
reader slot active--

writer 执行：

writer lock
    -> hash search
    -> hash delete
writer unlock
    -> synchronize_proc_cache_ref_acquirers()
    -> 转交或释放 hash 基础引用

这样 writer 不会在 reader 已经取得指针、但还没增加引用时释放 p。

---

四、从根本上取消 proc-events 忙等

提交：

8e2cf07 fix: defer proc cache reclamation

这是防止 proc-events 高 CPU 的根本兜底。

free_symbolizer_cache_kvp() 不再执行：

while (p->use != 0)
    CLIB_PAUSE();

现在改成：

if (AO_SUB_F(&p->use, 1) == 0)
    free_proc_cache(p);
else
    将 p 加入 retired_proc_caches;

后续 reap_retired_proc_caches() 周期扫描：

use == 0：摘除并释放
use > 0：跳过，下一次再检查

新时序：

Java/reader                  proc-events
    │                            │
    ├─ 持有 p->use               ├─ 从 hash 删除 p
    │                            ├─ 释放基础引用
    │                            ├─ 发现 use > 0
    │                            ├─ 放入 retired list
    │                            └─ 继续处理其他事件，不忙等
    │
    └─ p->use--                  后续 reaper
                                     ├─ 发现 use == 0
                                     └─ free_proc_cache(p)

即使以后再次发生引用长期不归还：

• proc-events 也不会占满 CPU。
• 只会有对象暂时停留在 retired list。
• 其他进程事件继续正常处理。

---

五、记录长期引用原因

提交：

5a05cd2 feat: record proc cache reference reason

在 symbolizer_proc_info 中增加原子原因标记：

PROC_USE_INC_REASON_UNKNOWN
PROC_USE_INC_REASON_HASH_QUERY
PROC_USE_INC_REASON_JAVA_TAST

重点记录两个可能长期持有引用的来源：

• Hash 查询。
• Java symbol task。

它记录的是“最近一次重要的引用增加原因”，便于判断 retired 对象为什么一直不能释放。

---

六、增加 retired list 诊断能力

提交：

de07b62 feat: expose proc cache reclamation diagnostics

增加：

• retired_proc_caches_lock 保护链表。
• retired_at_ns 记录首次进入 retired list 的单调时间。
• 等待时间、启动时间和基础内存统计。
• deepflow-ebpfctl 诊断命令。

命令：

deepflow-ebpfctl proc-cache-reclaim show --older-than 60

输出包括：

PID
COMM
USE
WAIT(s)
START_TIME
MEMORY
SYMCACHE
LAST_INC_REASON

以及 active、retired、超时数量和内存汇总。

---

七、增加 Proc Cache 总量上限

提交：

43496df feat: bound proc cache memory growth
f12aadd docs: clarify proc cache capacity accounting

如果某个引用永久不归还，retired list 虽然不会造成高 CPU，但仍可能持续占用内存。因此增加：

proc_cache_max_entries: 65536

范围：

1,024～262,144

统一限制：

total_count =
    初始化中
  + hash active
  + proc-event ring 中转
  + retired 等待释放

创建前预留容量名额，最终 free_proc_cache() 后归还。

达到上限后：

• 拒绝创建新的 Proc Cache。
• 已有查询、删除和回收继续运行。
• 不影响目标进程。
• 日志限频。
• 提供 rejected、reclaimed、retired、oldest wait 等运行指标。

普通 hash 查询热路径没有增加容量统计、容量锁或日志判断。

---

八、修复 ring 失败后的所有权泄漏

Proc Cache 已经从 hash 删除，但 proc_event_ring 分配或入队失败时，以前对象会变成无人负责：

hash 中没有 p
ring 中没有 p
retired list 中没有 p

现在 ring 失败后由当前线程处理：

free_symbolizer_cache_kvp(&kv);

根据引用情况：

use == 0：立即释放
use > 0：进入 retired list

避免对象、symbol cache 和容量名额永久泄漏。

---

九、增加远程诊断入口

deepflow-core 独立提交：

c2408af feat: expose proc cache diagnostics via remote exec

在 debug.rs 注册远程命令：

proc-cache-reclaim

支持：

• 可选 older-than。
• 默认 60 秒。
• 参数校验。
• 通过 RPC 调用 deepflow-ebpfctl。

---

最终效果

经过这一系列修改，现在形成了三层保护：

第一层：Java refresh 超时和 task 生命周期修复
        防止引用本身长期不归还

第二层：reader 生命周期保护 + retired 延迟回收
        即使引用未归还，也不发生 UAF、不让 proc-events 忙等

第三层：Proc Cache 总量限制
        即使引用永久泄漏，也不允许内存无限增长

最终保证：

• proc-events 不再因为等待 p->use == 0 耗尽一个 CPU。
• hash_search → use++ 不再存在释放竞态。
• Java symbol task 不再无限等待或访问已释放 task。
• 长期引用对象安全进入 retired list。
• 能看到等待时间、占用内存和引用原因。
• ring 失败不会丢失对象所有权。
• Proc Cache 对象总量存在硬上限。
• 正常 Proc Cache 查询热路径未增加全局容量锁。

当 Proc Cache 达到容量上限时，会立即打印一条 WARNING：
Proc cache limit reached: total=65536 limit=65536 active=54120 retired=11320 rejected=1823
此时不会继续创建新的 Proc Cache，避免内存无限增长。持续满载时，每两小时最多重复打印一次，防止进程风暴变成日志风暴。
容量恢复到上限以下时，会立即打印一条 INFO：
Proc cache capacity recovered: total=65480 limit=65536 rejected=1841

[yinjiping]

必须修改的问题

1. 修复 worker 获取错误 thread_index 的并发问题

位置：

• worker_thread()
• thread_pool_add_task()

当前通过共享变量传递新 worker 的索引：

pool->thread_index = pool->thread_count;
pthread_create(&thread, NULL, &worker_thread, pool);

worker 启动后再读取：

int thread_idx = pool->thread_index;

如果短时间连续创建两个 worker，第一个 worker 可能在线程启动较晚时读到第二个 worker 的 index，随后因为线程 ID 不匹配而退出：

if (pool->threads[thread_idx].thread != thread)
    pthread_exit(NULL);

可能造成：

• thread_count 仍包含已经退出的 worker；
• Java symbol task 永久留在 pending queue；
• collector 永远不启动；
• task/socket/refcount 长期不释放。

必须修改的原因

这是实际的任务永久卡住风险，而且当前 MR 正在修改同一段线程池创建逻辑。若不处理，MR 虽然修复了一类永久等待，但仍可能通过另一条路径制造永久 pending。

建议修改

不要使用共享的 pool->thread_index 传递 index。可以：

• 给每个 worker 传独立的 {pool, index} 启动参数；或
• worker 获取 pool->lock 后，通过 pthread_equal() 查找自己的 slot。

2. 修正 pthread_cond_timedwait() 的超时判断和 deadline

位置：

update_java_symbol_file()

当前实现：

while (task->need_refresh) {
    struct timespec ts;
    clock_gettime(CLOCK_REALTIME, &ts);
    ts.tv_sec += JAVA_SYMS_REFRESH_TIMEOUT_SECS;

    refresh_rc =
        pthread_cond_timedwait(&task->cond, &task->mutex, &ts);

    if (refresh_rc == ETIMEDOUT) {
        task->need_refresh = false;
        task->update_status = -1;
        break;
    }
}

这里有两个相关问题，应当合并成一个 Review 意见。

2.1 timeout 后没有重新检查 predicate

刷新完成和 timeout 可能同时发生。collector 可能已经执行：

task->update_status = 0;
task->need_refresh = false;
pthread_cond_signal(&task->cond);

但 pthread_cond_timedwait() 仍可能在边界条件下返回 ETIMEDOUT。当前代码会直接把成功结果覆盖成：

task->update_status = -1;

应该先检查：

if (!task->need_refresh)
    break;

只有 predicate 仍然为 true，才认定刷新超时。

2.2 deadline 不应在循环内重新计算

当前每次 spurious wakeup 都会重新获得 10 秒等待时间，因此不能严格保证整个调用最多等待 10 秒。

deadline 应在进入循环前计算一次，后续重复使用。

建议结构

struct timespec deadline;
clock_gettime(CLOCK_REALTIME, &deadline);
deadline.tv_sec += JAVA_SYMS_REFRESH_TIMEOUT_SECS;

while (task->need_refresh && !task->stopped) {
    int rc = pthread_cond_timedwait(
        &task->cond, &task->mutex, &deadline);

    /* 先检查业务条件，处理 signal/timeout 边界竞争。 */
    if (!task->need_refresh || task->stopped)
        break;

    if (rc != 0) {
        task->need_refresh = false;
        task->update_status = -1;
        break;
    }
}

更理想的是使用 CLOCK_MONOTONIC，但如果本 MR 希望控制范围，至少必须做到：

• deadline 只计算一次；
• timedwait 返回后先检查 predicate；
• 处理所有非零返回值。

必须修改的原因

“保证 Java symbol update 在有限时间内返回”是本 MR 的核心目标。如果 deadline 可以反复延长，或者成功结果会被 timeout 覆盖，说明核心等待逻辑还不完整。

合入前置条件

3. Rebase 最新 v6.6 并正确解决冲突

当前 PR 与 v6.6 存在冲突，相关 verify checks 也因此没有运行。

最新 v6.6 中已经存在大量 Java attach preflight 逻辑，而 MR 当前 head 中没有这些代码。解决冲突时必须保留：

• JVM 类型和版本检查；
• Java 8 安全版本限制；
• DisableAttachMechanism 检查；
• PID reuse 检查；
• namespace/version helper；
• preflight timeout 等逻辑。

这不需要写成一条具体的代码 Review comment，但它是合入的必要前提。冲突解决后需要重新看最终 diff。

不作为本 MR 阻塞项的问题

下面这些可以不要求当前 MR 修改：

proc-events 最多仍可能忙等 10 秒

while (AO_GET(&p->use) != 0)
    CLIB_PAUSE();

它确实意味着异常时仍可能短时间高 CPU，但本 MR 的核心价值是把“永久忙等”变成“有界等待”。如果团队接受这一行为，可以后续单独优化，不阻塞本 MR。

pthread_detach() 使用 errno 打印错误

这是错误日志准确性问题：

strerror(errno)

应该使用 pthread_detach() 的返回值，但不是核心稳定性问题，可以顺手改，也可以后续处理。

refcount assert、mutex/cond destroy

属于健壮性和代码规范优化，不是当前已确认的功能阻塞项。

正常刷新使用 broadcast

当前 Java symbol update 是单线程消费，通常只有一个 waiter，因此不要求本 MR 必须从 signal 改成 broadcast。

18564ae fix: make Java symbol refresh timeout reliable
09291ca fix: bind Java symbol workers to correct pool slots
已修复

[kylewanginchina]

下面这个问题还需要再看一下：