这个低频率出现的错误，核心原因是Perl的异步信号处理和主程序之间的竞态条件。当alarm触发save_stats子程序时，它会粗暴地打断主循环的执行流程——如果主程序刚好在执行$clients->{$sock->peerhost()}=1这行代码的中间步骤（比如刚完成哈希解引用，正要给对应key赋值），此时save_stats里的$clients={};会直接替换全局的哈希引用。

当主程序恢复执行时，它可能还在操作原来的哈希实例，而这个实例因为被中途打断，内部结构已经处于不一致的状态，甚至被标记为只读，最终触发"Modification of a read-only value attempted"错误。因为这种打断的时机非常苛刻，所以错误才会每月仅出现一次甚至更少。

最稳妥的方式是避免在信号处理程序中直接修改共享数据结构，改用"标志位通知"的方式，让主程序在自己的执行流程中安全地处理哈希重置。

修改后的代码示例： #

my $lsock = IO::Socket::INET->new(LocalPort=>$port, Proto=>'tcp', Listen=>1, Reuse=>1);
my $clients = {};
my $need_reset = 0;

# 信号处理程序只设置重置标志，不直接修改哈希
$SIG{ALRM} = sub {
    $need_reset = 1;
    alarm(60); # 安排下一次统计触发
};
alarm(60); # 启动首次统计定时器

while (1) {
    my $sock = $lsock->accept();
    if ($sock) {
        $clients->{$sock->peerhost()} = 1;
        # ... 其他客户端连接处理逻辑
    }

    # 在主循环的安全节点检查并处理重置
    if ($need_reset) {
        my $cnt = scalar keys %$clients;
        save_stats($cnt);
        $clients = {};
        $need_reset = 0;
    }
}

sub save_stats {
    my $cnt = shift;
    # ... 这里写你的统计保存逻辑（比如写入日志、数据库等）
}

为什么这个方案有效？ #

信号处理程序现在只做一件事：设置$need_reset标志。主程序会在每次循环的间隙（不会被中途打断的安全点）检查这个标志，然后自行完成哈希重置和统计保存。这样就彻底避免了信号中断哈希修改操作的竞态场景，从根源上消除了错误。

额外建议 #

如果你的统计逻辑更复杂，或者需要更高的安全性，可以考虑：

• 用封装的对象来管理$clients和重置逻辑，确保所有对统计数据的修改都通过受控的方法进行；
• 若涉及多进程/线程，可使用信号安全的锁机制（比如Thread::Semaphore）来保护共享数据，但单进程场景下标志位方案已经足够高效。

内容的提问来源于stack exchange，提问作者soger