이 글은 Golang과 Lua를 모두에게 소개하기 위해 go 언어튜토리얼 칼럼에서 소개한 글입니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다!
GitHub을 돌아다니던 중 우연히 순수 Golang으로 구현된 Lua 가상 머신인 gopher-lua를 발견했습니다. 우리는 Golang이 정적 언어인 반면 Lua는 동적 언어라는 것을 알고 있습니다. Golang의 성능과 효율성은 다른 언어 중에서 매우 우수하지만 동적 기능 측면에서는 확실히 Lua와 비교할 수 없습니다. 그래서 둘을 결합할 수 있다면 각각의 장점을 결합할 수 있습니다(설명서 웃기네요.
프로젝트 위키에서 우리는 gopher-lua의 실행 효율성과 성능이 C로 구현된 바인딩보다 나쁘다는 것을 알 수 있습니다. 따라서 성능 관점에서 볼 때 이것은 매우 좋은 가상 머신 솔루션이어야 합니다.
Hello World
다음은 간단한 Hello World 프로그램입니다. 그런 다음 여기에 DoString을 수행했습니다. lua 코드를 실행하는 작업을 수행하고 마지막으로 가상 머신을 종료합니다. 프로그램을 실행하면 명령줄에 "Hello World" 문자열이 표시됩니다.
package main import ( "github.com/yuin/gopher-lua" ) func main() { l := lua.NewState() defer l.Close() if err := l.DoString(`print("Hello World")`); err != nil { panic(err) } } // Hello World
미리 컴파일하세요
위의 DoString( ...) 메소드 호출 체인을 보면 DoString(...) 또는 DoFile(...)이 실행될 때마다 구문 분석과 컴파일이 한 번 실행된다는 것을 발견했습니다.
func (ls *LState) DoString(source string) error { if fn, err := ls.LoadString(source); err != nil { return err } else { ls.Push(fn) return ls.PCall(0, MultRet, nil) } } func (ls *LState) LoadString(source string) (*LFunction, error) { return ls.Load(strings.NewReader(source), "<string>") } func (ls *LState) Load(reader io.Reader, name string) (*LFunction, error) { chunk, err := parse.Parse(reader, name) // ... proto, err := Compile(chunk, name) // ... }
이를 고려하면 동일한 Lua 코드에서. 여러 번 실행되는 시나리오(예: http 서버에서는 각 요청에 대해 동일한 Lua 코드가 실행됨), 코드를 미리 컴파일할 수 있다면 구문 분석 및 컴파일의 오버헤드를 줄일 수 있어야 합니다. (핫패스 코드인 경우) .벤치마크 결과에 따르면 사전 컴파일을 사용하면 실제로 불필요한 오버헤드를 줄일 수 있습니다.
package glua_test import ( "bufio" "os" "strings" lua "github.com/yuin/gopher-lua" "github.com/yuin/gopher-lua/parse" ) // 编译 lua 代码字段 func CompileString(source string) (*lua.FunctionProto, error) { reader := strings.NewReader(source) chunk, err := parse.Parse(reader, source) if err != nil { return nil, err } proto, err := lua.Compile(chunk, source) if err != nil { return nil, err } return proto, nil } // 编译 lua 代码文件 func CompileFile(filePath string) (*lua.FunctionProto, error) { file, err := os.Open(filePath) defer file.Close() if err != nil { return nil, err } reader := bufio.NewReader(file) chunk, err := parse.Parse(reader, filePath) if err != nil { return nil, err } proto, err := lua.Compile(chunk, filePath) if err != nil { return nil, err } return proto, nil } func BenchmarkRunWithoutPreCompiling(b *testing.B) { l := lua.NewState() for i := 0; i < b.N; i++ { _ = l.DoString(`a = 1 + 1`) } l.Close() } func BenchmarkRunWithPreCompiling(b *testing.B) { l := lua.NewState() proto, _ := CompileString(`a = 1 + 1`) lfunc := l.NewFunctionFromProto(proto) for i := 0; i < b.N; i++ { l.Push(lfunc) _ = l.PCall(0, lua.MultRet, nil) } l.Close() } // goos: darwin // goarch: amd64 // pkg: glua // BenchmarkRunWithoutPreCompiling-8 100000 19392 ns/op 85626 B/op 67 allocs/op // BenchmarkRunWithPreCompiling-8 1000000 1162 ns/op 2752 B/op 8 allocs/op // PASS // ok glua 3.328s
가상 머신 인스턴스 풀
advanced를 사용하는 것 외에도 동일한 Lua 코드가 실행되는 경우 성능 최적화를 위해 가상 머신 인스턴스 풀을 도입할 수도 있습니다.
새로운 Lua 가상 머신을 생성하려면 많은 메모리 할당 작업이 필요하기 때문에 매번 다시 생성하고 삭제하는 방법을 사용하면
func BenchmarkRunWithoutPool(b *testing.B) { for i := 0; i < b.N; i++ { l := lua.NewState() _ = l.DoString(`a = 1 + 1`) l.Close() } } func BenchmarkRunWithPool(b *testing.B) { pool := newVMPool(nil, 100) for i := 0; i < b.N; i++ { l := pool.get() _ = l.DoString(`a = 1 + 1`) pool.put(l) } } // goos: darwin // goarch: amd64 // pkg: glua // BenchmarkRunWithoutPool-8 10000 129557 ns/op 262599 B/op 826 allocs/op // BenchmarkRunWithPool-8 100000 19320 ns/op 85626 B/op 67 allocs/op // PASS // ok glua 3.467s
벤치마크 결과에 따르면 가상 머신 인스턴스 풀은 실제로 많은 메모리 할당 작업을 줄일 수 있습니다.
README에서 제공하는 인스턴스 풀 구현은 다음과 같습니다. 구현이 초기 상태이므로 가상 머신 인스턴스가 충분하지 않으며(초기에는 인스턴스 수가 0임) 슬라이스의 동적 확장 문제가 있습니다.
type lStatePool struct { m sync.Mutex saved []*lua.LState } func (pl *lStatePool) Get() *lua.LState { pl.m.Lock() defer pl.m.Unlock() n := len(pl.saved) if n == 0 { return pl.New() } x := pl.saved[n-1] pl.saved = pl.saved[0 : n-1] return x } func (pl *lStatePool) New() *lua.LState { L := lua.NewState() // setting the L up here. // load scripts, set global variables, share channels, etc... return L } func (pl *lStatePool) Put(L *lua.LState) { pl.m.Lock() defer pl.m.Unlock() pl.saved = append(pl.saved, L) } func (pl *lStatePool) Shutdown() { for _, L := range pl.saved { L.Close() } } // Global LState pool var luaPool = &lStatePool{ saved: make([]*lua.LState, 0, 4), }
모듈 호출
gopher-lua는 Lua를 지원합니다. Go 모듈을 호출하는 것은 Golang 프로그램 개발에서 일반적으로 사용되는 많은 모듈을 설계할 수 있기 때문에 개인적으로 이것이 매우 흥미로운 기능이라고 생각합니다.
물론 Go를 호출하는 Lua 모듈도 있지만 개인적으로는 후자가 필요하지 않다고 느껴서 여기서는 다루지 않습니다.
package main import ( "fmt" lua "github.com/yuin/gopher-lua" ) const source = ` local m = require("gomodule") m.goFunc() print(m.name) ` func main() { L := lua.NewState() defer L.Close() L.PreloadModule("gomodule", load) if err := L.DoString(source); err != nil { panic(err) } } func load(L *lua.LState) int { mod := L.SetFuncs(L.NewTable(), exports) L.SetField(mod, "name", lua.LString("gomodule")) L.Push(mod) return 1 } var exports = map[string]lua.LGFunction{ "goFunc": goFunc, } func goFunc(L *lua.LState) int { fmt.Println("golang") return 0 } // golang // gomodule
가변 오염
오버헤드를 줄이기 위해 인스턴스 풀을 사용할 때 또 다른 까다로운 문제가 발생합니다. 동일한 가상 머신이 동일한 Lua 코드를 여러 번 실행하여 그 안의 전역 변수가 변경될 수 있기 때문입니다. 코드 논리가 전역 변수에 의존하는 경우 예측할 수 없는 실행 결과가 발생할 수 있습니다(이는 데이터베이스 격리에서 "반복 불가능한 읽기"와 약간 비슷합니다).
전역 변수
Lua 코드를 지역 변수만 사용하도록 제한해야 한다면, 여기서부터 전역 변수를 제한해야 합니다. 그렇다면 문제는 그것을 달성하는 방법입니다.
우리는 Lua가 바이트코드로 컴파일된 후 해석되고 실행된다는 것을 알고 있습니다. 그런 다음 바이트코드 컴파일 단계에서 전역 변수의 사용을 제한할 수 있습니다. Lua 가상 머신 명령어를 확인한 후 전역 변수와 관련된 두 가지 명령어, 즉 GETGLOBAL(Opcode 5) 및 SETGLOBAL(Opcode 7)이 있음을 발견했습니다.
이 시점에서 우리는 이미 일반적인 아이디어를 얻었습니다. 바이트코드에 GETGLOBAL 및 SETGLOBAL이 포함되어 있는지 판단하여 코드에서 전역 변수의 사용을 제한할 수 있습니다. 바이트코드를 얻으려면 CompileString(...) 및 CompileFile(...)을 호출하여 Lua 코드의 FunctionProto를 얻을 수 있으며 Code 속성은 []uint32 유형의 바이트코드 슬라이스입니다.
가상 머신 구현 코드에서는 바이트코드를 기반으로 해당 OpCode를 출력하는 도구 기능을 찾을 수 있습니다.
// 获取对应指令的 OpCode func opGetOpCode(inst uint32) int { return int(inst >> 26) }
이 도구 기능을 사용하면 전역 변수를 확인할 수 있습니다.
package main // ... func CheckGlobal(proto *lua.FunctionProto) error { for _, code := range proto.Code { switch opGetOpCode(code) { case lua.OP_GETGLOBAL: return errors.New("not allow to access global") case lua.OP_SETGLOBAL: return errors.New("not allow to set global") } } // 对嵌套函数进行全局变量的检查 for _, nestedProto := range proto.FunctionPrototypes { if err := CheckGlobal(nestedProto); err != nil { return err } } return nil } func TestCheckGetGlobal(t *testing.T) { l := lua.NewState() proto, _ := CompileString(`print(_G)`) if err := CheckGlobal(proto); err == nil { t.Fail() } l.Close() } func TestCheckSetGlobal(t *testing.T) { l := lua.NewState() proto, _ := CompileString(`_G = {}`) if err := CheckGlobal(proto); err == nil { t.Fail() } l.Close() }
모듈
오염될 수 있는 변수 외에도 가져온 Go 모듈도 런타임 중에 변조될 수 있습니다. 따라서 가상 머신으로 가져온 모듈이 변조되지 않도록 하는 메커니즘, 즉 가져온 개체가 읽기 전용인지 확인하는 메커니즘이 필요합니다.
관련 블로그를 확인한 후 Table의 __newindex 메소드를 수정하고 모듈을 읽기 전용 모드로 설정할 수 있습니다.
package main import ( "fmt" "github.com/yuin/gopher-lua" ) // 设置表为只读 func SetReadOnly(l *lua.LState, table *lua.LTable) *lua.LUserData { ud := l.NewUserData() mt := l.NewTable() // 设置表中域的指向为 table l.SetField(mt, "__index", table) // 限制对表的更新操作 l.SetField(mt, "__newindex", l.NewFunction(func(state *lua.LState) int { state.RaiseError("not allow to modify table") return 0 })) ud.Metatable = mt return ud } func load(l *lua.LState) int { mod := l.SetFuncs(l.NewTable(), exports) l.SetField(mod, "name", lua.LString("gomodule")) // 设置只读 l.Push(SetReadOnly(l, mod)) return 1 } var exports = map[string]lua.LGFunction{ "goFunc": goFunc, } func goFunc(l *lua.LState) int { fmt.Println("golang") return 0 } func main() { l := lua.NewState() l.PreloadModule("gomodule", load) // 尝试修改导入的模块 if err := l.DoString(`local m = require("gomodule");m.name = "hello world"`); err != nil { fmt.Println(err) } l.Close() } // <string>:1: not allow to modify table
마지막에 작성
Golang과 Lua의 통합으로 시야가 넓어졌습니다. 이러한 방식으로 정적 언어와 동적 언어를 통합할 수 있다는 사실이 밝혀졌습니다. 정적 언어의 작동 효율성이 높고 개발이 더 효율적입니다. 동적 언어의 효율성이 높습니다. 생각해보세요. 모두 흥분됩니다.
오랜 시간 동안 온라인으로 검색한 결과 Go-Lua에 대한 기술적인 공유가 없다는 것을 발견했습니다. 약간 관련된 기사(JD.com 레벨 3 목록 페이지의 지속적인 아키텍처 최적화 - Golang + Lua(OpenResty) 모범 사례)를 찾았습니다. ), 그리고 이 글에서 Lua는 여전히 C에서 실행되고 있습니다. 정보가 부족하고 저(학생 일행)의 개발 경험이 부족하여 실제 생산에서 이 솔루션의 타당성을 잘 평가할 수 없습니다. 그러므로 이 글은 '캐주얼 글'이라고밖에 볼 수 없습니다. 하하.
위 내용은 Golang과 Lua가 만나면 어떤 불꽃이 일어날까요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!