Python代碼一鍵轉Jar包及Java調用Python新姿勢
需求背景
進擊的Python
隨著人工智能的興起,Python這門曾經小眾的編程語言可謂是煥發(fā)了第二春。
以tensorflow、pytorch等為主的機器學習/深度學習的開發(fā)框架大行其道,助推了python這門曾經以爬蟲見長(python粉別生氣)的編程語言在TIOBE編程語言排行榜上一路披荊斬棘,坐上前三甲的寶座,僅次于Java和C,將C++、JavaScript、PHP、C#等一眾勁敵斬落馬下。
當然,軒轅君向來是不提倡編程語言之間的競爭對比,每一門語言都有自己的優(yōu)勢和劣勢,有自己應用的領域。
另一方面,TIOBE統(tǒng)計的數據也不能代表國內的實際情況,上面的例子只是側面反映了Python這門語言如今的流行程度。
Java 還是 Python
說回咱們的需求上來,如今在不少的企業(yè)中,同時存在Python研發(fā)團隊和Java研發(fā)團隊,Python團隊負責人工智能算法開發(fā),而Java團隊負責算法工程化,將算法能力通過工程化包裝提供接口給更上層的應用使用。
可能大家要問了,為什么不直接用Java做AI開發(fā)呢?要弄兩個團隊。其實,現在包括TensorFlow在內的框架都逐漸開始支持Java平臺,用Java做AI開發(fā)也不是不行(軒轅君的前同事就已經在這樣做了),但限于歷史原因,做AI開發(fā)的人本就不多,而這一些人絕大部分都是Python技術棧入坑,Python的AI開發(fā)生態(tài)已經建設的相對完善,所以造成了在很多公司中算法團隊和工程化團隊使用不同的語言。
現在該拋出本文的重要問題:Java工程化團隊如何調用Python的算法能力?
答案基本上只有一個:Python通過Django/Flask等框架啟動一個Web服務,Java中通過Restful API與之進行交互
上面的方式的確可以解決問題,但隨之而來的就是性能問題。尤其是在用戶量上升后,大量并發(fā)接口訪問下,通過網絡訪問和Python的代碼執(zhí)行速度將成為拖累整個項目的瓶頸。
當然,不差錢的公司可以用硬件堆出性能,一個不行,那就多部署幾個Python Web服務。
那除此之外,有沒有更實惠的解決方案呢?這就是這篇文章要討論的問題。
給Python加速
尋找方向
上面的性能瓶頸中,拖累執(zhí)行速度的原因主要有兩個:
- 通過網絡訪問,不如直接調用內部模塊快
- Python是解釋執(zhí)行,快不起來
眾所周知,Python是一門解釋型腳本語言,一般來說,在執(zhí)行速度上:
解釋型語言 < 中間字節(jié)碼語言 < 本地編譯型語言
自然而然,我們要努力的方向也就有兩個:
- 能否不通過網絡訪問,直接本地調用
- Python不要解釋執(zhí)行
結合上面的兩個點,我們的目標也清晰起來:
將Python代碼轉換成Java可以直接本地調用的模塊
對于Java來說,能夠本地調用的有兩種:
- Java代碼包
- Native代碼模塊
其實我們通常所說的Python指的是CPython,也就是由C語言開發(fā)的解釋器來解釋執(zhí)行。而除此之外,除了C語言,不少其他編程語言也能夠按照Python的語言規(guī)范開發(fā)出虛擬機來解釋執(zhí)行Python腳本:
- CPython: C語言編寫的解釋器
- Jython: Java編寫的解釋器
- IronPython: .NET平臺的解釋器
- PyPy: Python自己編寫的解釋器(雞生蛋,蛋生雞)
Jython?
如果能夠在JVM中直接執(zhí)行Python腳本,與Java業(yè)務代碼的交互自然是最簡單不過。但隨后的調研發(fā)現,這條路很快就被堵死了:
- 不支持Python3.0以上的語法
- python源碼中若引用的第三方庫包含C語言擴展,將無法提供支持,如numpy等
這條路行不通,那還有一條:把Python代碼轉換成Native代碼塊,Java通過JNI的接口形式調用。
Python -> Native代碼
整體思路
先將Python源代碼轉換成C代碼,之后用GCC編譯C代碼為二進制模塊so/dll,接著進行一次Java Native接口封裝,使用Jar打包命令轉換成Jar包,然后Java便可以直接調用。
流程并不復雜,但要完整實現這個目標,有兩個關鍵問題需要解決:
1.Python代碼如何轉換成C代碼?
終于要輪到本文的主角登場了,將要用到的一個核心工具叫:Cython
請注意,這里的Cython和前面提到的CPython不是一回事。CPython狹義上是指C語言編寫的Python解釋器,是Windows、Linux下我們默認的Python腳本解釋器。
而Cython是Python的一個第三方庫,你可以通過pip install Cython
進行安裝。
官方介紹Cython是一個Python語言規(guī)范的超集,它可以將Python+C混合編碼的.pyx腳本轉換為C代碼,主要用于優(yōu)化Python腳本性能或Python調用C函數庫。
聽上去有點復雜,也有點繞,不過沒關系,get一個核心點即可:Cython能夠把Python腳本轉換成C代碼
來看一個實驗:
# FileName: test.py def test_function(): print("this is print from python script")
將上述代碼通過Cython轉化,生成test.c,長這個樣子:
另外添加一個main.c,在其中實現C語言的main函數,并調用原python中的函數:
extern void test_function(); int main() { test_function(); return 0; }
輸出結果:
可以正常工作!
2.轉換后的C代碼如何包裝成JNI接口使用
實際動手
1.Python源代碼
def logic(param): print('this is a logic function') # 接口函數,導出給Java Native的接口 def JNI_API_TestFunction(param): print("enter JNI_API_test_function") logic(param) print("leave JNI_API_test_function")
2.使用Cython工具轉換成C代碼
3.編譯生成動態(tài)庫
4.封裝為Jar包
準備一個JNI調用的Interface:JNITest.java
public class JNITest { native boolean Java_PkgName_module_initModule( ); native void Java_PkgName_module_uninitModule( ); native String Java_PkgName_module_TestFunction(String param); }
這里有3個native方法:
- initModule: 對應C代碼中Java_JNITest_initModule(),主要完成Python初始化
- uninitModule: 對應C代碼中Java_JNITest_uninitModule(),主要完成Python反初始化
- TestFunction: 對應C代碼中的Java_JNITest_TestFunction(),為核心業(yè)務接口
接口聲明文件+二進制動態(tài)庫文件準備就緒,開始打包:
jar -cvf JNITest.jar ./JNITest
5.Java調用
關鍵問題
1.import問題
上面演示的案例只是一個單獨的py文件,而實際工作中,我們的項目通常是具有多個py文件,并且這些文件通常是構成了復雜的目錄層級,互相之間各種import關系,錯綜復雜。
Cython這個工具有一個最大的坑在于:經過其處理的文件代碼中會丟失代碼文件的目錄層級信息,如下圖所示,C.py轉換后的代碼和m/C.py生成的代碼沒有任何區(qū)別。
這就帶來一個非常大的問題:A.py或B.py代碼中如果有引用m目錄下的C.py模塊,目錄信息的丟失將導致二者在執(zhí)行import m.C時報錯,找不到對應的模塊!
幸運的是,經過實驗表明,在上面的圖中,如果A、B、C三個模塊處于同一級目錄下時,import能夠正確執(zhí)行。
軒轅君曾經嘗試閱讀Cython的源代碼,并進行修改,將目錄信息進行保留,使得生成后的C代碼仍然能夠正常import,但限于時間倉促,對Python解釋器機理了解不足,在一番嘗試之后選擇了放棄。
在這個問題上卡了很久,最終選擇了一種笨辦法:將樹形的代碼層級目錄展開成為平坦的目錄結構,就上圖中的例子而言,展開后的目錄結構變成了
A.py
B.py
m_C.py
單是這樣還不夠,還需要對A、B中引用到C的地方全部進行修正為對m_C的引用。
這看起來很簡單,但實際情況遠比這復雜,在Python中,import可不只有import這么簡單,有各種各樣復雜的形式:
import package import module import package.module import module.class / function import package.module.class / function import package.* import module.* from module import * from module import module from package import * from package import module from package.module import class / function ...
除此之外,在代碼中還可能存在直接通過模塊進行引用的寫法。
展開成為平坦結構的代價就是要處理上面所有的情況!軒轅君無奈之下只有出此下策,如果各位大佬有更好的解決方案還望不吝賜教。
2.Python GIL問題
Python轉換后的jar包開始用于實際生產中了,但隨后發(fā)現了一個問題:
每當Java并發(fā)數一上去之后,JVM總是不定時出現Crash
隨后分析崩潰信息發(fā)現,崩潰的地方正是在Native代碼中的Python轉換后的代碼中。
- 難道是Cython的bug?
- 轉換后的代碼有坑?
- 還是說上面的import修正工作有問題?
崩潰的烏云籠罩在頭上許久,冷靜下來思考:
為什么測試的時候正常沒有發(fā)現問題,上線之后才會崩潰?
再次翻看崩潰日志,發(fā)現在native代碼中,發(fā)生異常的地方總是在malloc分配內存的地方,難不成內存被破壞了?
又敏銳的發(fā)現測試的時候只是完成了功能性測試,并沒有進行并發(fā)壓力測試,而發(fā)生崩潰的場景總是在多并發(fā)環(huán)境中。多線程訪問JNI接口,那Native代碼將在多個線程上下文中執(zhí)行。
猛地一個警覺:99%跟Python的GIL鎖有關系!
眾所周知,限于歷史原因,Python誕生于上世紀九十年代,彼時多線程的概念還遠遠沒有像今天這樣深入人心過,Python作為這個時代的產物一誕生就是一個單線程的產品。
雖然Python也有多線程庫,允許創(chuàng)建多個線程,但由于C語言版本的解釋器在內存管理上并非線程安全,所以在解釋器內部有一個非常重要的鎖在制約著Python的多線程,所以所謂多線程實際上也只是大家輪流來占坑。
原來GIL是由解釋器在進行調度管理,如今被轉成了C代碼后,誰來負責管理多線程的安全呢?
由于Python提供了一套供C語言調用的接口,允許在C程序中執(zhí)行Python腳本,于是翻看這套API的文檔,看看能否找到答案。
幸運的是,還真被我找到了:
獲取GIL鎖:
釋放GIL鎖:
在JNI調用入口需要獲得GIL鎖,接口退出時需要釋放GIL鎖。
加入GIL鎖的控制后,煩人的Crash問題終于得以解決!
測試效果
準備兩份一模一樣的py文件,同樣的一個算法函數,一個通過Flask Web接口訪問,(Web服務部署于本地127.0.0.1,盡可能減少網絡延時),另一個通過上述過程轉換成Jar包。
在Java服務中,分別調用兩個接口100次,整個測試工作進行10次,統(tǒng)計執(zhí)行耗時:
上述測試中,為進一步區(qū)分網絡帶來的延遲和代碼執(zhí)行本身的延遲,在算法函數的入口和出口做了計時,在Java執(zhí)行接口調用前和獲得結果的地方也做了計時,這樣可以計算出算法執(zhí)行本身的時間在整個接口調用過程中的占比。
- 從結果可以看出,通過Web API執(zhí)行的接口訪問,算法本身執(zhí)行的時間只占到了30%+,大部分的時間用在了網絡開銷(數據包的收發(fā)、Flask框架的調度處理等等)。
- 而通過JNI接口本地調用,算法的執(zhí)行時間占到了整個接口執(zhí)行時間的80%以上,而Java JNI的接口轉換過程只占用10%+的時間,有效提升了效率,減少額外時間的浪費。
- 除此之外,單看算法本身的執(zhí)行部分,同一份代碼,轉換成Native代碼后的執(zhí)行時間在300~500μs,而CPython解釋執(zhí)行的時間則在2000~4000μs,同樣也是相差懸殊。
總結
本文提供了一種Java調用Python功能的新思路,僅供參考,其成熟度和穩(wěn)定性還有待商榷,通過HTTP Restful接口訪問仍然是跨語言對接的首選。
到此這篇關于Python代碼一鍵轉Jar包及Java調用Python新姿勢的文章就介紹到這了,更多相關Python轉Jar包內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!