PHP 實(shí)現(xiàn)base64編碼文件上傳出現(xiàn)問題詳解

一、場景

領(lǐng)導(dǎo)：小A同學(xué)，我們要做一個(gè)樣本上傳進(jìn)行分析的功能，你看下是否使用base64編碼加進(jìn)去，這樣客戶端的同學(xué)就不需要用form-data方式來上傳了，直接使用json格式就可以上報(bào)，可以讓格式上報(bào)統(tǒng)一。

小A：好的，領(lǐng)導(dǎo)，馬上搞定！

咋看上面的對話沒啥問題，很多公司團(tuán)隊(duì)內(nèi)部為了一些標(biāo)準(zhǔn)化的問題，都會進(jìn)行一些技術(shù)選型問題，但是噩夢也就從這個(gè)對話開始，功能實(shí)現(xiàn)當(dāng)然都是很簡單的，先來看簡單流程圖：

本身的流程是一個(gè)很簡單的文件轉(zhuǎn)換成base64上傳，再服務(wù)端decode保存，在開發(fā)聯(lián)調(diào)過程中沒有問題，非常完美的走下去了。

二、問題來了

突然有一天終端同學(xué)誤操作將一個(gè)37M文件上傳，nginx與php-fpm文件上傳限制均為（60M），但是在界面出現(xiàn)500錯(cuò)誤，進(jìn)入docker 日志查看有一條數(shù)據(jù)：

Allowed memory size of 8388608 bytes exhausted (tried to allocate 1298358 bytes)

玩php的基本都知道這是啥意思，就是代碼運(yùn)行過程中使用內(nèi)存超過 我們php.ini設(shè)置的memory_limit 的值，然后就屁顛屁顛進(jìn)入php.ini找參數(shù)配置，很快找到：

memory_limit=128M

然后就轉(zhuǎn)念一想，不應(yīng)該出現(xiàn)這個(gè)問題，我們知道，php的內(nèi)部變量使用cow（寫時(shí)復(fù)制）機(jī)制來實(shí)現(xiàn)，那么內(nèi)存申請只有在變量賦值變更才會進(jìn)行

三、測驗(yàn)

接下來我們單獨(dú)寫一個(gè)程序來進(jìn)行測試，將一個(gè)4.89M文件進(jìn)行base64_encode 編碼 與base64_decode解碼，查看各自占用內(nèi)存以及過程中占用峰值內(nèi)存

?php
$mid = memory_get_usage();
$apk_content = file_get_contents(__DIR__ . '/4bc1c8a05b8505662be778b6dad23b55.apk');
var_dump('文件加載到內(nèi)存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('過程中峰值使用的內(nèi)存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');

unset($mid);
$mid = memory_get_usage();
$base64_encode = base64_encode($apk_content);unset($apk_content);
var_dump('base64_encode占用內(nèi)存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('過程中峰值使用的內(nèi)存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');

unset($mid);
$mid = memory_get_usage();
base64_decode($base64_encode);
var_dump('base64_decode占用內(nèi)存：' . round((memory_get_usage() - $mid) / 1024 / 1024, 2) . 'M');
var_dump('過程中峰值使用的內(nèi)存：' . round(memory_get_peak_usage() / 1024 / 1024, 2) . 'M');
unset($mid);

執(zhí)行結(jié)果：

string(29) "文件加載到內(nèi)存：4.89M"
string(38) "過程中峰值使用的內(nèi)存：5.25M"
string(33) "base64_encode占用內(nèi)存：1.63M"
string(39) "過程中峰值使用的內(nèi)存：11.76M"
string(30) "base64_decode占用內(nèi)存：0M"
string(38) "過程中峰值使用的內(nèi)存：13.4M"

通過上面結(jié)果可以看出

• 加載文件使用內(nèi)存沒有太大問題，加載過程使用的峰值在5.25M，高出整體文件大小不多，這在文件加載過程有一些臨時(shí)申請內(nèi)存的問題
• base64_encode占用內(nèi)存，這個(gè)在使用的時(shí)候，就已經(jīng)將內(nèi)存差不多進(jìn)行一個(gè)double，而這基本上也是在內(nèi)核解析過程中，進(jìn)行了內(nèi)存申請，可以理解，文件本身占用內(nèi)存+base64_encode 解析后的內(nèi)存，兩份內(nèi)存同時(shí)存在的
• base64_decode操作，這個(gè)操作就是解密了，解密過程中，這里直接就占用了3倍多的內(nèi)存操作，問題就出在這里，在場景中出現(xiàn)的問題是一個(gè)37M的文件，為什么就把單個(gè)fpm的128M內(nèi)存占滿了呢

四、源碼解析

base64_encode源碼解析

首先找到對應(yīng)的c文件 base64.c,找到里面php_base64_encode函數(shù)

PHPAPI zend_string *php_base64_encode(const unsigned char *str, size_t length) /* {{{ */
{
	const unsigned char *current = str;
	unsigned char *p;
	zend_string *result;

	result = zend_string_safe_alloc(((length + 2) / 3), 4 * sizeof(char), 0, 0);
	p = (unsigned char *)ZSTR_VAL(result);
    ...
}

我們先來分析這段代碼，因?yàn)檫@里涉及到內(nèi)存的問題，那么我們就看

result = zend_string_safe_alloc(((length + 2) / 3), 4 * sizeof(char), 0, 0);

這啥意思呢？

申請內(nèi)存，最終調(diào)用的函數(shù)是：

safe_emalloc(size_t nmemb, size_t size, size_t offset)

在wiki上解釋是：

void *safe_emalloc(size_t nmemb, size_t size, size_t offset)分配緩沖區(qū)來存放每塊大小為 size 字節(jié)的 nmemb 塊，并附加 offset 字節(jié)。類似于 emalloc(nmemb * size + offset)，但增加了針對溢出的特殊保護(hù)。

那么我可以簡單的認(rèn)為，就是在encode過程中，重新申請了內(nèi)存，申請的內(nèi)存大小是文件本身的 4/3 大小，加上原來的文件本身大小，那么峰值大小可以理解為

峰值內(nèi)存= 7/3 *4.89 = 11.41

那么與我們實(shí)驗(yàn)過程中峰值大小基本是相符。

base64_decode操作

同樣我們進(jìn)行源碼分析

PHPAPI zend_string *php_base64_decode_ex(const unsigned char *str, size_t length, zend_bool strict) /* {{{ */
{
	const unsigned char *current = str;
	int ch, i = 0, j = 0, padding = 0;
	zend_string *result;

	result = zend_string_alloc(length, 0);
	...
}

這里使用的zend_string_alloc來進(jìn)行申請內(nèi)存，那么底層使用的函數(shù)就是emalloc函數(shù)，來看下wiki的解釋

void *emalloc(size_t size)分配 size 字節(jié)的內(nèi)存。

這個(gè)就比較好理解了，傳入?yún)?shù)內(nèi)存再進(jìn)行一個(gè)double拷貝就可以，

那么我們進(jìn)行一個(gè)decode的內(nèi)存峰值的計(jì)算：

峰值內(nèi)存=(4/3+4/3) *4.89 =13.04

基本與我們測試的結(jié)果相差不多，因?yàn)榫汝P(guān)系，我們進(jìn)行四舍五入的計(jì)算，測試代碼是精準(zhǔn)計(jì)算，所以會有小數(shù)點(diǎn)偏差。

五、總結(jié)

那這就可以理解為什么一個(gè)為什么在我們一個(gè)37M的文件，不能再128M內(nèi)存進(jìn)行base64_encode與base64_decode操作，當(dāng)然這里有一些臨時(shí)變量沒有及時(shí)釋放內(nèi)存的情況，但是通過源碼分析可以知道，要做一次這樣場景來進(jìn)行文件上傳，單純文件的內(nèi)存損耗是2.6倍左右，所以為了節(jié)省內(nèi)存，我們不要再用這個(gè)方式來進(jìn)行操作了，很費(fèi)內(nèi)存的

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。