Skip to content

Lazy Services

Warning: You are browsing the documentation for Symfony 5.x, which is no longer maintained.

Read the updated version of this page for Symfony 7.2 (the current stable version).

See also

Other ways to inject services lazily are via a service closure or service subscriber.

Why Lazy Services?

In some cases, you may want to inject a service that is a bit heavy to instantiate, but is not always used inside your object. For example, imagine you have a NewsletterManager and you inject a mailer service into it. Only a few methods on your NewsletterManager actually use the mailer, but even when you don't need it, a mailer service is always instantiated in order to construct your NewsletterManager.

Configuring lazy services is one answer to this. With a lazy service, a "proxy" of the mailer service is actually injected. It looks and acts like the mailer, except that the mailer isn't actually instantiated until you interact with the proxy in some way.

Caution

Lazy services do not support final or readonly classes, but you can use Interface Proxifying to work around this limitation.

In PHP versions prior to 8.0 lazy services do not support parameters with default values for built-in PHP classes (e.g. PDO).

Installation

In order to use the lazy service instantiation, you will need to install the symfony/proxy-manager-bridge package:

1
$ composer require symfony/proxy-manager-bridge

Configuration

You can mark the service as lazy by manipulating its definition:

1
2
3
4
# config/services.yaml
services:
    App\Twig\AppExtension:
        lazy: true

Once you inject the service into another service, a virtual proxy with the same signature of the class representing the service should be injected. The same happens when calling Container::get() directly.

The actual class will be instantiated as soon as you try to interact with the service (e.g. call one of its methods).

To check if your proxy works you can check the interface of the received object:

1
2
dump(class_implements($service));
// the output should include "ProxyManager\Proxy\LazyLoadingInterface"

Note

If you don't install the ProxyManager bridge , the container will skip over the lazy flag and directly instantiate the service as it would normally do.

You can also configure your service's laziness thanks to the Autoconfigure attribute. For example, to define your service as lazy use the following:

1
2
3
4
5
6
7
8
9
10
namespace App\Twig;

use Symfony\Component\DependencyInjection\Attribute\Autoconfigure;
use Twig\Extension\ExtensionInterface;

#[Autoconfigure(lazy: true)]
class AppExtension implements ExtensionInterface
{
    // ...
}

5.4

The Autoconfigure attribute was introduced in Symfony 5.4.

Interface Proxifying

Under the hood, proxies generated to lazily load services inherit from the class used by the service. However, sometimes this is not possible at all (e.g. because the class is final and can not be extended) or not convenient.

To workaround this limitation, you can configure a proxy to only implement specific interfaces.

1
2
3
4
5
6
7
8
# config/services.yaml
services:
    App\Twig\AppExtension:
        lazy: 'Twig\Extension\ExtensionInterface'
        # or a complete definition:
        lazy: true
        tags:
            - { name: 'proxy', interface: 'Twig\Extension\ExtensionInterface' }

Just like in the Configuration section, you can use the Autoconfigure attribute to configure the interface to proxify by passing its FQCN as the lazy parameter value:

1
2
3
4
5
6
7
8
9
10
namespace App\Twig;

use Symfony\Component\DependencyInjection\Attribute\Autoconfigure;
use Twig\Extension\ExtensionInterface;

#[Autoconfigure(lazy: ExtensionInterface::class)]
class AppExtension implements ExtensionInterface
{
    // ...
}

5.4

The Autoconfigure attribute was introduced in Symfony 5.4.

The virtual proxy injected into other services will only implement the specified interfaces and will not extend the original service class, allowing to lazy load services using final classes. You can configure the proxy to implement multiple interfaces by adding new "proxy" tags.

Tip

This feature can also act as a safe guard: given that the proxy does not extend the original class, only the methods defined by the interface can be called, preventing to call implementation specific methods. It also prevents injecting the dependency at all if you type-hinted a concrete implementation instead of the interface.

Additional Resources

You can read more about how proxies are instantiated, generated and initialized in the documentation of ProxyManager.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version