扫描进程内存需要注意加锁

      最近在搞扫描进程内存部门,但是偶尔会出现蓝屏的问题,经过分析是进程已退出,但是还是在对这个进程扫描。其中在扫描之前,需要attach到这个进程上去的,但是为什么会出现这样的一个情况呢。首先我查看了wrk,rectos和nt4,也使用windbg分析了进程结束和读取进程内存部分的代码。发现ms在对进程结束之前会去获取一个进程锁,其中在PspExitThread一开始,会发现这个地方一开始就要检测进程是否被attach上了,如果坚持的就立马回调用bugcheck的。为了尽量的避免这样的蓝屏出现,我选在在attch进程之前先获取进程锁,防止进程退出,造成的蓝屏。

       这个进程锁,在2000系统上时PsLockProcess和PsUnlockProcess进行的。至于如果获取这两个函数的地址可以参见

通过PspTerminateThreadByPointer结束进程”中减少。而在xp以及以上系统ms使用了例外的一种方法是通过eprocess中的rundownprotect这个字段进行加锁的。其中在nt中有到处ExAcquireRundownProtection和ExReleaseRundownProtection这两个函数进行的。好在这两个函数都是在nt中有导出的,那么就简单的多了,可以使用MmGetSystemRoutine得到的。这两个函数的参数是&(eProcess->RundownProtect)的地址。

### Java FTP 文件锁定机制 在Java中实现FTP文件加锁功能可以通过多种方式完成。以下是几种常见的方法及其优缺点: #### 方法一:基于同步的文件访问控制 可以利用`Synchronized`关键字来确保同一时间只有一个线程能够操作特定的FTP文件资源[^2]。这种方式简单易懂,但在分布式环境中可能不够灵活。 ```java public class FtpFileLock { private static final Object LOCK = new Object(); public void accessFtpFile(String fileName) { synchronized (LOCK) { System.out.println(Thread.currentThread().getName() + " accessing " + fileName); // 模拟文件处理逻辑 try { Thread.sleep(1000); // 延迟模拟长时间的操作 } catch (InterruptedException e) { throw new RuntimeException(e); } System.out.println(Thread.currentThread().getName() + " finished processing " + fileName); } } } ``` 这种方法适用于单机环境下的多个线程共享同一个FTP客户端实例的情况。然而,在跨机器或多节点的情况下,这种简单的同步无法满足需求。 --- #### 方法二:使用显式的锁管理器 通过引入`ReentrantLock`或其他并发工具类,可以在更细粒度上控制对FTP文件的访问权限[^2]。例如,创建一个全局锁表用于跟踪哪些文件当前被占用。 ```java import java.util.Map; import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; public class FtpFileLockManager { private Map<String, Lock> locks = new ConcurrentHashMap<>(); public void acquireLock(String fileName) { locks.putIfAbsent(fileName, new ReentrantLock()); Lock lock = locks.get(fileName); lock.lock(); System.out.println(Thread.currentThread().getName() + " acquired lock on " + fileName); } public void releaseLock(String fileName) { Lock lock = locks.get(fileName); if (lock != null && lock.isHeldByCurrentThread()) { lock.unlock(); System.out.println(Thread.currentThread().getName() + " released lock on " + fileName); } } } ``` 此方案适合于需要动态分配和释放锁的应用场景,并且支持可重入特性(即同一线程多次获取相同锁不会死锁)。不过需要注意的是,如果程序意外崩溃而未正常释放某些锁,则可能导致永久性的阻塞问题。 --- #### 方法三:借助外部配置库或服务协调锁状态 对于复杂的分布式系统来说,单独依靠本地内存中的数据结构难以可靠地维护一致的状态信息。此时可以选择集成专门设计用来解决这类难题的相关框架或者中间件产品[^3]。比如Redis、ZooKeeper等都可以作为可靠的分布式锁解决方案的基础组件之一;另外还有像Apache Curator这样的高级封装API可以直接提供开箱即用的功能模块供开发者调用。 下面是一个基于Curator实现基本读写互斥模式的例子: ```java import org.apache.curator.framework.CuratorFramework; import org.apache.curator.framework.CuratorFrameworkFactory; import org.apache.curator.framework.recipes.locks.InterProcessMutex; import org.apache.curator.retry.ExponentialBackoffRetry; public class DistributedFtpFileLock { private final String zkConnectionString = "localhost:2181"; private final CuratorFramework client = CuratorFrameworkFactory.newClient(zkConnectionString, new ExponentialBackoffRetry(1000, 3)); public DistributedFtpFileLock(){ this.client.start(); } public void lockFile(String filePath){ InterProcessMutex lock = new InterProcessMutex(client,"/" + filePath.replace("/","_")); try{ lock.acquire(); System.out.println("Locked "+filePath+" successfully."); // Perform your operation here... }catch(Exception ex){ ex.printStackTrace(); }finally{ try{if(lock!=null){lock.release();}}catch(Exception ignore){} } } } ``` 上述代码片段展示了如何利用Zookeeper配合Curator构建分布式的文件级独占型锁。它不仅解决了传统进程间通信带来的复杂性挑战,还具备良好的容错能力和扩展潜力。 --- #### 死锁预防措施 无论采用哪种技术路线图都需要警惕可能出现的死锁状况。正如之前提到过的那样当两个以上的事务相互等待对方持有的资源时就会形成循环依赖关系从而引发僵局现象[^1]。为了避免这种情况发生可以从以下几个方面入手改进设计方案: - **按顺序申请资源**: 如果所有的参与者都遵循固定的次序去请求不同的对象那么就不会存在交叉交错的现象。 - **设置超时时限**: 给每次尝试获得许可设定最大允许持续的时间一旦超过该阈值则自动放弃此次竞争机会重新排队等候下一轮轮询。 - **主动检测并解除冲突**: 定期扫描整个系统的运行情况发现潜在的风险点及时介入调整策略打破现有的束缚链条恢复正常运转流程。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值