解決 JScript.NET 超彈性條件式運算器疑案

今天解掉一個糾纏十餘年的老茶包，有治好數十年痼疾的痛快，特 PO 文紀念。

某個古老系統有個進階客製需求，允許設計者在定義作業流程時可以撰寫自訂規則，用預先定義好的資料變數符號(例如：$FieldA、$Now...)配合大於、小於、AND、OR 寫出複雜的判斷條件式，還要能支援括號優先順序。當年的我找到一個取巧解法，將條件式中的系統變數展開翻譯成 JavaScript if 條件式，再丟給 JavaScript 引擎運算傳回 true 或 false。如此就算寫出 ($FieldA % 4 > 0 && ($FieldB == 'A' || $FieldC.indexOf('I') == 0)) 這種鬼算式，展開成 ( 140 % 4 == 0 && ('A' == 'A' || 'IIS'.indexOf('I') == 0)) 丟給 JavaScript 引擎照樣瞬間得到答案。 (資安提醒：大家如果想仿效應用，務必要留意程式碼注入風險)

實作原理是借用被遺忘的 JScript.NET 語言，寫一段 JScript 函式傳回 eval() 結果編譯成 .NET 組件，便可以 .NET 中跑 JavaScript 指令做運算，以下是簡單示範：

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(JSEvaluator.Eval("1+1"));
        Console.WriteLine(JSEvaluator.Eval("1 == 1 || 4 > 5"));
        Console.WriteLine(
            JSEvaluator.Eval("(140 % 4 == 0 && ('A' == 'A' || 'IIS'.indexOf('I') == 0))");
    }
}

public class JSEvaluator
{
    static Type _jseType = null;
    static object _jse = null;
    static JSEvaluator()
    {
        var provider = CodeDomProvider.CreateProvider("JScript");
        var p = new CompilerParameters();
        p.GenerateInMemory = true;
        CompilerResults r = provider.CompileAssemblyFromSource(p,
@"class JSEvaluator {  
public function Eval(expr : String) : String { return eval(expr); } 
}");
        Assembly asm = r.CompiledAssembly;
        _jseType = asm.GetType("JSEvaluator");
        _jse = Activator.CreateInstance(_jseType);
    }

    public static string Eval(string expr)
    {
        return _jseType.InvokeMember("Eval", BindingFlags.InvokeMethod,
            null, _jse, new object[] { expr }).ToString();
    }
}

不過呢，這個系統跑了十幾年，一年會出現幾次異常，JSEvaluator.Eval 運算出現 "'Exception has been thrown by the target of an invocation" 或 "Object reference not set to an instance of an object" 錯誤，之後無法執行 JavaScript 運算式，直到重啟 ASP.NET 網站恢復。但由於發生頻率很低又不知如何重現，再加上它是被世人遺忘的 JScript.NET，我很鄉愿地做出粗暴結論 - 這是 JScript.NET 不定期發生的 Bug，微軟也不會再更新了，既然頻率不高，遇到重啟 AppPool 便是。

最近，異常發生頻率提高到兩三個月一次，讓人無法繼續忽視，我開始思索解法。已做好改借用 Node.js 的心理準備，但工程有點大，且系統架構會變複雜，當涉及元件愈多，故障機率愈高，亦是隱憂。

無法下決心砍掉重練，再爬文碰碰運氣，幸運地在 MSDN 論壇找到幾乎一模一樣的案例。啊! 是 Thread-Safe 問題!

這樣就能解釋為什麼測試環境沒遇到，線上環境也久久才會發生一次。該判斷邏輯執行的頻率不算高，一整天才幾千次，每次執行時間又小於 1ms，剛好兩個使用者在同一毫秒執行很需要運氣。

依此原理，將程式小改為 Parallel.ForEach 多緒執行，立刻成功重現問題：

知道原因根源，解決只在彈指之間。用 lock (_jseType) 把 _jseType.InvokeMember("Eval"...) 包起來，問題瞬間消除：

    public static string Eval(string expr)
    {
        lock (_jseType)
        {
            return _jseType.InvokeMember("Eval", BindingFlags.InvokeMethod,
                null, _jse, new object[] { expr }).ToString();
        }
    }

事後自我檢討，為什麼放任這個 Bug 存在如此多年？出現頻率不高影響不大，而且重啟一下就能解決是主要原因，因為不太痛也就不會積極追查；第二點則是因為 JScript.NET 屬古老技術，我先入為主下了「很久沒更新 + 很少人用 + 有 Bug 也沒人發現 + 找到 Bug 也不會修正」的草率結論，說穿了是欠缺實事求是精神，有違茶包射手的專業，未來應以此為戒。最後還有一點，我對 Thread-Safe 問題的 Sense 還不夠強，壓根沒想過它是兇手，下回遇到測試環境 OK，上線久久才會炸一次的問題，應該要優先排除多緒環境因素。

Experience of solving a JScript.NET thread-safe issue.