As mentioned, can you give a detailed reason? Thank you.
As mentioned, can you give a detailed reason? Thank you.
Most of the concurrency we usually talk about is for services, such as apache nginx
instead of php
In addition, php is multi-threaded, but it is not used in daily projects
Define multi-threaded class extends Thread
In fact, this sentence itself is ambiguous.
First look at the prerequisites:
<code>php不支持多线程 </code>
The PHP language code itself (in most cases) does not care whether it is multi-process or multi-threaded. However, this does not mean that PHP does not support multi-threading/multi-processing. php-fpm is multi-process and single-threaded, and apeche's multi-threaded mode is multi-threaded. PHP just generally doesn't control processes or threads directly at the PHP code level.
<code>不用考虑并发问题 </code>
If the premise is not established, the conclusion will have no causal relationship.
I understand the original intention of the person who said this is: because PHP generally does not support controlling processes and threads, it will not directly control processes and threads through code to deal with concurrency issues.
There is nothing wrong with saying that.
However, concurrency problems are still concurrency problems. Concurrency problems do not exist just because the PHP code itself does not support solving concurrency problems.
The conventional way to solve PHP concurrency problems is through various configuration adjustments (nginx.conf, php-fpm.ini, php.ini) and then load balancing. These are not PHP codes, but they are things closely related to PHP that you need to master as a PHPer.
In addition, PHP logic can be modified for specific business types, and even front-end calling logic is available. There are also extensions such as swoole that completely abandon php-fpm, and basically support asynchronous concurrency in PHP (however, it is still single-threaded). These concurrency optimization methods must be selected based on specific businesses.
Wrong, you are wrong!
PHP does not support multi-threading, but the background operation of the command line program or the php-fpm of the web application can be processed concurrently by multiple processes, so concurrency problems cannot be avoided. For example, one order has one inventory, and two concurrent processes How do you ensure that orders are not oversold when requests come in at the same time?
Even if multi-threading is not considered, concurrency still exists and is more difficult to solve. We still need to find ways to avoid and optimize it
Concurrency is only multi-threading? This is too narrow
PHP inherently supports multi-threading, so there is a difference between thread safety and non-thread safety.
For PHP multi-thread extension, please see:
https://pecl.php.net/package/pthreads
This extension provides practical Real PHP multi-thread programming support, generally used for script programming under cli.
In addition, foreigner Feng Ge also developed an extension Swoole that provides an asynchronous multi-thread architecture to support the development of high-performance real-time network services with PHP:
https: //pecl.php.net/package/swoole
Multi-threading in Swoole does not require programmers to care. It is more like a set of architectures. You only need to configure it. Swoole is generally used for script programming under cli.
Like the PHP FastCGI service PHP-FPM, which is often used with Nginx, it uses multiple processes to implement multi-core response to concurrency, similar to Apache using prefork MPM. PHP-FPM supports process pool settings, supports static and dynamic process number settings, and supports Natural transparent "database connection pool" (persistent connection):
MOD_PHP also works in a multi-threaded state when running with Apache using event MPM, because Apache event MPM is a multi-process multi-thread event-driven MPM, which is the thread-safe version that PHP needs to use.