JavaScript 怎么模拟 个 析构方法

JavaScript018

JavaScript 怎么模拟 个 析构方法,第1张

自己实现一个框架,所有的对象都从框架中一个包含析构函数和destroy方法的基类继承。每个子类实现自己的析构函数,对象销毁时都调用destroy方法。

业务基于这个框架开发即可。

首先我们来定义LockingPtr用到的Mutex类的骨架:

class Mutex

{

public:

void Acquire()

void Release()

...

}

为了能使用LockingPtr,你要用你操作系统用到的数据结构和基本函数来实现Mutex。

LockingPtr用受控的变量的类型来作为模板。举例来说,如果你想管理一个Widget,你使用一个LockingPtr<Widget>,这样你可以用一个类型为volatile Widget的变量来初始化它。

LockingPtr的定义非常简单。LockingPtr实现一个相对简单的smart pointer。它目的只是把一个const_cast和一个临界区集中在一起。

Template <typename T>

Class LockingPtr {

Public:

//构造/析构函数

LockingPtr(volatile T&obj, Mutex&mtx)

: pObj_(const_cast<T*>(&obj)),

pMtx_(&mtx)

{ mtx.Lock()}

~LockingPtr()

{ pMtx_->Unlock()}

//模拟指针行为

T&operator*()

{ return *pObj_}

T* operator->()

{ return pObj_}

private:

T* pObj_

Mutex* pMtx_

LockingPtr(const LockingPtr&)

LockingPtr&operator=(const LockingPtr&)

}

尽管简单,LockingPtr对写出正确的多线程代码非常有帮助。你应该把被几个线程共享的对象定义为volatile而且不能对它们使用const_cast——应该始终使用LockingPtr自动对象。我们通过一个例子来说明:

假设你有两个线程共享一个vector<char>对象

class SyncBuf {

public:

void Thread1()

void Thread2()

private:

typedef vector<char>BufT

volatile BufT buffer_

Mutex mtx_//控制对buffer_的访问

}软件开发网

在一个线程函数中,你简单地使用一个LockingPtr<BufT>来取得对buffer_成员变量的受控访问:

void SyncBuf::Thread1() {

LockingPtr<BufT>lpBuf(buffer_, mtx_)

BufT::iterator I = lpBuf->begin()

For (I != lpBuf->end()I) {

...使用*i...

}

}

这些代码既非常容易写也非常容易懂——任何时候你需要用到buffer_,你必须创建一个LockingPtr<BufT>指向它。一旦你这样做,你就能够使用vecotr的所有接口。

非常好的事情是,如果你犯了错,编译器会指出来:

void SyncBuf::Thread2() {

//错误,不能对一个volatile对象调用begin()

BufT::iterator I = buffer_.begin()

//错误!不能对一个volatile对象调用end()

for (I != lpBuf->end()I) {

...使用*i...

}

}

你不能调用buffer_的任何函数,除非你要么使用一个const_cast要么使用LockingPtr。区别是LockingPtr提供了一个有序的途径来对volatile变量使用const_cast。

LockingPtr非常有表现力。如果你只需要调用一个函数,你能够创建一个无名临时LockingPtr对象并直接使用它:

Unsigned int SyncBuf::Size() {

Return LockingPtr<BufT>(buffer_, mtx_)->size()

}

回到基本类型

我们已经看到了volatile保护对象不被不受控制地访问时是多么出色,也看到了LockingPtr提供了多么简单和高效的方法来写线程安全的代码。让我们回到基本类型,那些加了volatile后行为与用户自定类型不同的类型

我们来考虑一个例子,多个线程共享一个类型为int的变量。

Class Count

{

public:

...

void Increment() { ctr_}

void Decrement() { --ctr_}

private:

int ctr_

}

如果Increment和Decrement被不同线程调用,上面的代码片段是有问题的。首先,ctr_必须是volatile,其次,即使象 ctr_那样看上去是原子操作的函数实际上是一个三步操作。内存本身没有算术能力,当递增一个变量时,处理器:

* 读取那个变量到寄存器

* 在寄存器中增加值

* 把结果写回内存

这个三步操作叫做RMW(Read-ModifyWrite 读-改-写)。在执行一个RMW操作的“改”

操作时,为了让其他处理器访问内存,大多数处理器会释放内存总线。

如果那时另一个处理器对同一个变量执行一个RMW操作,我们就有了一个竟态条件;第二个写操作覆盖了第一个的结果。

你也能够用LockingPtr避免这种情况:

class Counter

{

public:

...

void Increment() { *LockingPtr<int>(ctr_, mtx_)}

void Decrement() { --*LockingPtr<int>(ctr_, mtx_)}

private:

volatile int ctr_

Mutex mtx_

}

现在代码正确了,但代码质量比较SyncBuf的代码而言差了很多。为什么?因为在Counter里,如果你错误地直接访问ctr_(没有先对它加锁)编译器不会警告你。如果ctr_是volatile, ctr_也能编译通过,但产生的代码明显是错误的。编译器不再是你的帮手了,只有靠你自己注意才能避免这样的竟态条件。

那你应该怎么做?简单地把你用到的基本数据包装为更高层次的结构,对那些结构用volatile。荒谬的是,尽管本来volatile的用途是用在内建类型上,但实际上直接这样做不是个好主意!

volatile成员函数

到目前为止,我们已经有了包含有volatile数据成员的类,现在我们来考虑设计作为更大对象一部分的类,这些类也被多线程共享。在这里用volatile成员函数有很大帮助。

当设计你的类时,你只对那些线程安全的成员函数加voaltile标识。你必须假定外部代码会用任何代码在任何时刻调用volatile函数。不要忘记:volatile等于可自由用于多线程代码而不用临界区,非volatile等于单线程环境或在一个临界区内。

例如,你定义一个Widget类,实现一个函数的两个变化——一个线程安全的和一个快的,无保护的。

Class Widget

{

public:

void Operation() volatile

void Operation()

...

private:

Mutex mtx_

}

注意用了重载。现在Widget的用户可以用同样的语法来调用Operation,无论你为了获得线程安全调用volatile对象的Operation还是为了获得速度调用常规对象的Operation。但用户必须小心地把被多线程共享的Widget对象定义为volatile。

当实现一个volatile成员函数时,第一个操作通常是对this用一个LockingPtr加锁。剩下的工作可以交给非volatile的对应函数:

软件开发网

void Widget::Operation() volatile

{

LockingPtr<Widget>lpThis(*this, mtx_)

LpThis->Operation()//调用非volatile函数

} http://www.mscto.com

总结

当写多线程程序时,你可以用volatile得到好处。你必须遵守下面的规则:

* 定义所有的被共享的对象为volatile。

* 不要对基本类型直接用volatile

* 当定义可被共享类时,使用volatile成员函数来表示线程安全。

如果你这样做,而且如果你使用那个简单的返型组件LockingPtr,你能够写出线程安

全的代码而不用更多考虑竟态条件,因为编译器能为你留心,会为你主动指出你错误的地方。

我参与的几个使用volatile和LockingPtr的计划获得很好的效果。代码清晰易懂。我记得碰到几处死锁,但我情愿遇到死锁也不要竟态条件,因为死锁调试起来容易得多。事实上没有遇到任何问题是关于竟态条件的。

首先告诉你 if(a==0) { a++ } if(a==7) { a-- } 这段代码没用,想象一下当a=0进入如程序,加一下等1,等于1再进入程序,然后就没用了,你的程序我怎么看不到一个分号out of memory这个问题其实不容易被发现,因为只有经过实践的积累才会看到结果。各位往往没有耐心等到他的发生,但是它确实在某些条件下存在。废话不多说,分析问题。原因:setTimeout定时器惹的祸深层原因:setTimeout的应用往往伴随着某个函数的递归,这个过程中系统会始终开辟一部分内存空间等待着递归的结束。但是我们广大的js程序员往往没有结束递归的习惯,甚至认为这段内存会在某一时间段之内自动回收,GOD,这就是js的内存泄露了!!解决方法:如果你有面向对象的开发习惯的话那是最好的,设置一个成员变量否则设置一个全局变量var timer(js的弱数据类型声明真的很够呛)用来记录定时器对象。然后设置一个成员变量或者全局变量计数器var cnt,每执行一次递归计数器自增一次,当达到一定的数量的递归之后析构定时器对象。例子: 会导致内存泄露: function func1() { window.setTimeout("func1()",1000) }改进后的程序: var timervar cnt=0function func1(){cnt++ if(cnt>1000) { window.clearTimeout(timer) cnt=0 } timer = window.setTimeout("func1()",1000) }