me_javascript 기술을 통해 JScript 버그 및 메모리 관리 배우기

1. JScript 버그

JScript의 IE의 ECMAScript 구현은 명명된 함수 표현식을 심각하게 혼동시켜 많은 사람들이 명명된 함수 표현식에 반대하게 만들고 심지어 아직 사용 중인 버전(IE8에서 사용되는 버전 5.8)도 여전히 존재한다는 질문을 던집니다.

IEE가 구현 과정에서 어떤 실수를 했는지 살펴보겠습니다. 속담처럼 적을 알아야만 무적이 될 수 있습니다. 다음 예를 살펴보겠습니다.

예시 1: 외부 범위로 유출된 함수 표현식의 식별자

var f = function g(){};
typeof g; // "function"

앞서 명명된 함수 표현식의 식별자가 외부 범위에서 유효하지 않다고 말했지만 JScript는 분명히 이 사양을 위반합니다. 위 예에서 식별자 g는 함수 개체로 구문 분석됩니다. 예, 많은 부분이 복잡합니다. -to-find 버그는 이런 이유로 발생합니다.

참고: 이 문제는 IE9에서 수정된 것 같습니다

예 2: 명명된 함수 표현식을 함수 선언과 함수 표현식 모두로 처리

typeof g; // "function"
var f = function g(){};

기능 환경에서는 함수 선언이 표현식보다 먼저 구문 분석됩니다. 위의 예는 JScript가 실제 선언보다 먼저 g를 구문 분석하기 때문에 실제로 명명된 함수 표현식을 함수 선언으로 처리한다는 것을 보여줍니다.

이 예시는 다음 예시로 이어집니다.

예 3: 명명된 함수 표현식은 완전히 다른 두 개의 함수 객체를 생성합니다!

var f = function g(){};
f === g; // false
f.expando = 'foo';
g.expando; // undefined

이것을 보면 모든 사람이 문제가 심각하다고 생각할 것입니다. 어떤 개체를 수정해도 다른 개체는 변경되지 않기 때문입니다. 이 예를 통해 우리는 두 개의 서로 다른 객체를 생성한다는 것을 알 수 있습니다. 즉, f의 속성을 수정하여 특정 정보를 저장한 다음 g의 동일한 이름 속성을 참조하여 당연히 사용하려는 경우입니다. 동일한 개체라면 큰 문제가 발생할 것입니다. 왜냐하면 그것은 단순히 불가능하기 때문입니다.

좀 더 복잡한 예를 살펴보겠습니다.

예 4: 함수 선언만 순차적으로 구문 분석하고 조건문 블록을 무시합니다

var f = function g() {
  return 1;
};
if (false) {
 f = function g(){
 return 2;
 };
}
g(); // 2

이 버그는 찾기가 훨씬 어렵지만 버그의 원인은 매우 간단합니다. 먼저 g는 함수 선언으로 해석됩니다. JScript의 함수 선언은 조건부 코드 블록의 적용을 받지 않기 때문에 이 불쾌한 if 분기에서는 g가 다른 함수 function g(){ return 2 }로 처리되고, 또한 다시 선언되었습니다. . 그런 다음 모든 "정규" 표현식이 평가되고 f에는 새로 생성된 다른 객체에 대한 참조가 제공됩니다. 표현식이 평가될 때 끔찍한 if 분기 ""가 입력되지 않으므로 f는 계속해서 첫 번째 함수 function g(){ return 1 }을 참조합니다. 이를 분석한 후에 문제는 매우 명확합니다. 충분히 주의해서 f에서 g를 호출하면 관련 없는 g 함수 객체가

이라고 호출됩니다.

argument.callee를 사용하여 다양한 객체를 비교할 때 차이점이 무엇인지 물어볼 수 있습니다. 살펴보겠습니다:

var f = function g(){
  return [
  arguments.callee == f,
  arguments.callee == g
  ];
};
f(); // [true, false]
g(); // [false, true]

보시다시피, 인수.callee의 참조는 항상 호출된 함수입니다. 사실 이것도 나중에 설명하겠지만 좋은 것입니다.

또 다른 흥미로운 예는 선언이 포함되지 않은 대입문에서 명명된 함수 표현식을 사용하는 것입니다.

(function(){
 f = function f(){};
})();

코드 분석에 따르면 원래는 전역 속성 f를 만들고 싶었습니다(이름이 지정된 선언을 사용하는 일반 익명 함수와 혼동하지 않도록 주의하세요). 먼저 여기서 표현식을 변경했습니다. 표현식은 함수 선언으로 해석되므로 왼쪽의 f는 지역 변수로 선언됩니다(일반 익명 함수의 선언과 동일). 그러면 함수가 실행될 때 f는 이미 정의되어 있으며 함수 f( ) 오른쪽의 {}는 로컬 변수 f에 직접 할당되므로 f는 전혀 전역 속성이 아닙니다.

JScript가 얼마나 비정상적인지 이해한 후에는 먼저 식별자가 외부 범위로 유출되는 것을 방지해야 합니다. 둘째, 함수 이름으로 사용되는 식별자는 이전 예의 식별자를 인용해서는 안 됩니다. g? ——g가 존재하지 않는 척할 수 있다면 얼마나 불필요한 문제를 피할 수 있을까요? 따라서 핵심은 항상 f 또는args.callee를 통해 함수를 참조하는 것입니다. 명명된 함수 표현식을 사용하는 경우 디버깅할 때 해당 이름만 사용해야 합니다. 마지막으로 명명된 함수 표현식을 선언하는 동안 잘못 생성된 함수를 정리해야 합니다.

2. JScript 메모리 관리

이러한 비표준 코드 구문 분석 버그를 알고 나면 이를 사용하면 실제로 메모리에 문제가 있음을 알 수 있습니다. 예를 살펴보겠습니다.

var f = (function(){
 if (true) {
 return function g(){};
 }
 return function g(){};
})();

我们知道，这个匿名函数调用返回的函数（带有标识符g的函数），然后赋值给了外部的f。我们也知道，命名函数表达式会导致产生多余的函数对象，而该对象与返回的函数对象不是一回事。所以这个多余的g函数就死在了返回函数的闭包中了，因此内存问题就出现了。这是因为if语句内部的函数与g是在同一个作用域中被声明的。这种情况下 ，除非我们显式断开对g函数的引用，否则它一直占着内存不放。

var f = (function(){
 var f, g;
 if (true) {
 f = function g(){};
 }
 else {
 f = function g(){};
 }
 // 设置g为null以后它就不会再占内存了
 g = null;
 return f;
})();

通过设置g为null，垃圾回收器就把g引用的那个隐式函数给回收掉了，为了验证我们的代码，我们来做一些测试，以确保我们的内存被回收了。

测试

测试很简单，就是命名函数表达式创建10000个函数，然后把它们保存在一个数组中。等一会儿以后再看这些函数到底占用了多少内存。然后，再断开这些引用并重复这一过程。下面是测试代码：

function createFn(){
 return (function(){
 var f;
 if (true) {
  f = function F(){
  return 'standard';
  };
 }
 else if (false) {
  f = function F(){
  return 'alternative';
  };
 }
 else {
  f = function F(){
  return 'fallback';
  };
 }
 // var F = null;
 return f;
 })();
}

var arr = [ ];
for (var i=0; i < 10000; i++) {
 arr[i] = createFn();
}

通过运行在Windows XP SP2中的任务管理器可以看到如下结果：

IE7:

 without `null`: 7.6K -> 20.3K
 with `null`:  7.6K -> 18K

IE8:

 without `null`: 14K -> 29.7K
 with `null`:  14K -> 27K

如我们所料，显示断开引用可以释放内存，但是释放的内存不是很多，10000个函数对象才释放大约3M的内存，这对一些小型脚本不算什么，但对于大型程序，或者长时间运行在低内存的设备里的时候，这是非常有必要的。

以上就是关于JScript的Bug与内存管理的全部介绍，希望对大家的学习有所帮助。