目录
- 一、代理模式的概念
-
- [1.1 代理模式的定义](#1.1 代理模式的定义)
- [1.2 代理模式的适用场景](#1.2 代理模式的适用场景)
- [1.3 代理模式的结构](#1.3 代理模式的结构)
- 二、常见代理类型的实战应用
-
- [2.1 静态代理的实现](#2.1 静态代理的实现)
- [2.2 动态代理的实现](#2.2 动态代理的实现)
- [2.3 远程代理（RPC 场景）与本地代理的区别](#2.3 远程代理（RPC 场景）与本地代理的区别)
- 三、代理模式的实战技巧
-
- [3.1 代理模式与装饰器模式的区别](#3.1 代理模式与装饰器模式的区别)
- [3.2 代理模式的线程安全处理](#3.2 代理模式的线程安全处理)
- [3.3 代理模式的性能优化](#3.3 代理模式的性能优化)
- 四、实战项目：图片加载缓存系统（代理版）
-
- [4.1 项目需求](#4.1 项目需求)
- [4.2 代理模式实现图片加载缓存逻辑](#4.2 代理模式实现图片加载缓存逻辑)
- [4.3 缓存命中率测试与性能优化](#4.3 缓存命中率测试与性能优化)
一、代理模式的概念
1.1 代理模式的定义
代理模式，作为一种结构型设计模式，其定义为：为其他对象提供一种代理以控制对它的访问。在实际生活中，我们常常能接触到代理模式的例子，比如租房时找房产中介。当我们想要租房，却对房源信息了解有限，直接联系房东又较为麻烦时，房产中介就充当了我们与房东之间的代理角色。中介掌握大量房源信息，我们只需与中介沟通需求，中介便会依据这些需求筛选合适房源，安排看房等事宜，控制我们对房东以及房源信息的访问。
在程序设计领域，假设有一个复杂的数据库操作对象，直接访问它可能需要繁琐的权限验证、连接管理等操作。这时，我们可以创建一个代理对象，客户端通过代理对象来访问数据库操作对象。代理对象负责处理权限验证、连接建立与关闭等操作，控制客户端对真实数据库操作对象的访问，让客户端能更简洁地使用数据库功能。
1.2 代理模式的适用场景
- 远程代理：在分布式系统中，当客户端需要访问远程服务器上的对象时，远程代理发挥重要作用。比如，客户端想要调用远程服务器上的某个服务，若直接访问，需处理复杂的网络通信细节，如建立连接、序列化与反序列化数据等。通过远程代理，客户端只需像调用本地对象一样调用代理对象的方法，代理对象负责与远程服务器通信，将请求发送到远程对象，并接收远程对象的响应返回给客户端。像常见的 RPC（远程过程调用）框架，就广泛应用了远程代理模式，极大简化分布式系统中远程服务的调用过程。
- 安全代理：在系统中，有些对象包含敏感信息或关键操作，只允许特定用户或角色访问。例如，一个财务系统中，涉及财务数据修改的操作，只有财务主管及以上权限的人员才能执行。此时，可通过安全代理来控制对这些敏感操作的访问。安全代理在客户端调用真实对象的方法前，先进行权限验证，若客户端具备相应权限，则允许访问真实对象执行操作；若权限不足，直接拒绝访问并返回错误信息，从而保障系统安全性。
- 缓存代理：当获取某个对象的结果代价较高，如需要进行复杂计算或多次数据库查询时，缓存代理能有效提升系统性能。以查询热门文章的评论数为例，每次查询都从数据库读取数据并计算评论数量，开销较大。利用缓存代理，首次查询时，代理将结果缓存起来，后续再有相同查询请求，直接从缓存中返回结果，避免重复计算和数据库查询，减少系统开销，提高响应速度。
- 虚拟代理：适用于创建对象成本高或资源消耗大的场景，如加载大图片、大文件等。比如在图片浏览器中，若要显示一张高分辨率的大图片，直接加载可能导致程序卡顿甚至内存溢出。通过虚拟代理，在图片未被真正显示时，先创建一个较小的占位符对象代表图片，当用户真正需要查看图片细节时，再加载真实的大图片，有效提升程序的响应速度和用户体验。
1.3 代理模式的结构
代理模式主要包含以下三个关键部分：
- 抽象主题（Subject）：通过接口或抽象类的形式，声明真实主题和代理主题共同的业务方法。它是客户端与真实对象交互的统一接口，定义了一组方法规范，确保代理对象和真实对象具有一致的行为，使得客户端可以以相同的方式访问代理对象和真实对象。例如，在上述租房场景中，抽象主题可以是一个租房接口，定义了 "查找房源""预约看房" 等方法。
- 真实主题（RealSubject）：实现抽象主题接口，是实际执行具体业务逻辑的对象，即代理所代表的真实对象。在租房场景中，真实主题就是房东，拥有实际的房源，能够执行出租房屋相关的具体操作，如展示房源、协商租金等。
- 代理主题（Proxy）：同样实现抽象主题接口，持有对真实主题的引用。它在客户端和真实主题之间起到中介作用，控制对真实主题的访问。在访问真实主题的方法前后，代理主题可以添加额外的操作，如权限检查、日志记录、缓存处理等。在租房场景中，房产中介就是代理主题，持有房东（真实主题）的相关信息，在为租客提供服务（调用房东的方法）时，会先对租客的需求进行了解和筛选（额外操作），再联系房东安排看房等事宜。
用 UML 类图表示代理模式的结构如下：
cpp
@startuml
interface Subject {
+request()
}
class RealSubject implements Subject {
+request()
}
class Proxy implements Subject {
-realSubject: RealSubject
+request()
}
Client --> Proxy: 使用代理对象
Proxy --> RealSubject: 持有真实对象引用
@enduml在这个类图中，Client 通过 Proxy 来访问 RealSubject，Proxy 持有 RealSubject 的引用，并且实现了 Subject 接口，使得 Proxy 可以替代 RealSubject 被 Client 使用。
二、常见代理类型的实战应用
2.1 静态代理的实现
静态代理是指在编译期就确定代理关系，代理类和被代理类的关系在编译时就已经明确。代理类和被代理类都实现相同的接口，代理类通过持有被代理类的实例，来调用被代理类的方法，同时可以在调用前后添加额外的逻辑。
下面是一个简单的 C++ 静态代理示例，以租房场景为例，定义一个租房接口RentHouse，真实主题Landlord实现该接口，代理主题Agent同样实现该接口并持有Landlord的实例：
cpp
#include <iostream>
#include <string>
// 抽象主题：租房接口
class RentHouse {
public:
virtual void rent() = 0;
virtual ~RentHouse() {}
};
// 真实主题：房东
class Landlord : public RentHouse {
public:
void rent() override {
std::cout << "房东出租房屋" << std::endl;
}
};
// 代理主题：房产中介
class Agent : public RentHouse {
private:
Landlord* landlord;
public:
Agent() {
landlord = new Landlord();
}
~Agent() {
delete landlord;
}
void rent() override {
std::cout << "中介了解租客需求" << std::endl;
landlord->rent();
std::cout << "中介协助签订合同" << std::endl;
}
};在上述代码中，RentHouse是抽象主题，定义了rent方法。Landlord是真实主题，实现了rent方法，表示房东出租房屋的具体操作。Agent是代理主题，持有Landlord的指针，并在rent方法中，先执行了解租客需求的操作，再调用房东的rent方法，最后执行协助签订合同的操作。通过这种方式，代理类控制了对真实类的访问，并在访问前后添加了额外的业务逻辑。
2.2 动态代理的实现
动态代理与静态代理不同，它是在运行期生成代理对象。在 C++ 中，虽然没有像 Java 那样原生的动态代理机制，但可以借助一些库来实现类似的功能，比如libffi库。libffi库可以在运行时动态调用函数，结合 C++ 的模板、反射等技术，可以实现动态代理。
实现动态代理的关键步骤如下：
- 定义抽象主题接口，与静态代理中的抽象主题类似。
- 创建一个调用处理器（InvocationHandler），用于处理代理对象的方法调用。在调用处理器中，可以实现对真实对象方法的调用，以及在调用前后添加额外逻辑。
- 使用相关库（如libffi）生成代理对象，代理对象的方法调用会被转发到调用处理器中进行处理。
下面是一个简化的动态代理示例框架（假设已经集成libffi库）：
cpp
#include <iostream>
#include <functional>
#include <map>
// 抽象主题：示例接口
class Subject {
public:
virtual void request() = 0;
virtual ~Subject() {}
};
// 真实主题：示例实现
class RealSubject : public Subject {
public:
void request() override {
std::cout << "RealSubject执行请求" << std::endl;
}
};
// 调用处理器
class InvocationHandler {
public:
virtual void invoke(const std::string& methodName) = 0;
virtual ~InvocationHandler() {}
};
// 动态代理工厂
class DynamicProxy {
public:
static Subject* newProxyInstance(Subject* realSubject, InvocationHandler* handler) {
// 这里使用libffi等库的相关函数生成代理对象，实际实现较为复杂，此处简化示意
// 代理对象的方法调用会转发到handler的invoke方法
return new Proxy(realSubject, handler);
}
private:
class Proxy : public Subject {
private:
Subject* realSubject;
InvocationHandler* handler;
public:
Proxy(Subject* real, InvocationHandler* h) : realSubject(real), handler(h) {}
void request() override {
handler->invoke("request");
realSubject->request();
handler->invoke("after_request");
}
};
};
// 具体的调用处理器实现
class MyInvocationHandler : public InvocationHandler {
private:
Subject* realSubject;
public:
MyInvocationHandler(Subject* real) : realSubject(real) {}
void invoke(const std::string& methodName) override {
if (methodName == "request") {
std::cout << "代理预处理" << std::endl;
}
else if (methodName == "after_request") {
std::cout << "代理后续处理" << std::endl;
}
}
};在上述示例中，Subject是抽象主题接口，RealSubject是真实主题。InvocationHandler是调用处理器接口，MyInvocationHandler是其具体实现，用于处理代理对象的方法调用前后的逻辑。DynamicProxy是动态代理工厂，负责生成代理对象，其中的Proxy类是代理对象的实现，将方法调用转发到调用处理器和真实对象。通过这种方式，实现了在运行时动态生成代理对象，并控制对真实对象的访问。
2.3 远程代理（RPC 场景）与本地代理的区别
- 通信方式 ：
- 远程代理（RPC 场景）：主要用于分布式系统中，实现跨网络、跨进程的通信。客户端通过远程代理调用远程服务器上的对象方法时，涉及网络通信，需要将方法调用的参数进行序列化，通过网络传输到远程服务器，远程服务器接收到请求后进行反序列化，调用真实对象的方法，再将结果序列化返回给客户端。例如，在一个基于 RPC 框架的微服务架构中，服务 A 调用服务 B 的某个方法，服务 A 中的远程代理会将调用信息通过网络发送到服务 B 所在的服务器。
- 本地代理：在同一进程内工作，代理对象和真实对象处于同一内存空间，方法调用通过函数调用的方式直接进行，不涉及网络通信，只是在调用前后可能添加一些本地的逻辑处理，如权限检查、日志记录等。例如，在一个本地应用程序中，使用本地代理来控制对某个数据库操作类的访问。
- 性能影响 ：
- 远程代理（RPC 场景）：由于涉及网络通信，网络延迟、带宽限制等因素会对性能产生较大影响。网络传输过程中，数据的序列化和反序列化也会消耗一定的时间和资源。此外，网络的不稳定性可能导致请求超时、连接中断等问题，需要额外的重试、容错机制来保证调用的可靠性。
- 本地代理：因为在同一进程内，方法调用速度快，几乎没有网络延迟的影响。本地代理的性能开销主要来自于代理对象添加的额外逻辑处理，如日志记录、权限验证等操作，但这些开销相对网络通信来说较小。
- 应用场景 ：
- 远程代理（RPC 场景）：适用于分布式系统中，不同服务之间的远程调用，实现服务的分布式部署和协同工作。例如，在大型电商系统中，订单服务、库存服务、支付服务等可能部署在不同的服务器上，通过远程代理实现服务之间的相互调用。
- 本地代理：主要用于本地应用程序中，对一些复杂对象的访问控制、功能增强等。比如，在一个图形渲染程序中，使用本地代理来延迟加载大纹理资源，提高程序的启动速度和响应性能。
三、代理模式的实战技巧
3.1 代理模式与装饰器模式的区别
代理模式和装饰器模式在结构上有一定相似性，都涉及一个代理或装饰对象来封装真实对象，但它们的设计目的和应用场景有显著区别。
- 控制访问与扩展功能：代理模式的核心目的是控制对真实对象的访问，在客户端和真实对象之间起到中介作用，负责处理权限验证、远程调用、缓存等操作，确保只有合法的访问才能到达真实对象。例如，在一个权限管理系统中，代理对象负责检查客户端的权限，只有具有相应权限的用户才能访问真实的资源对象。而装饰器模式主要用于动态地给对象添加额外的职责或功能，不改变对象的接口，而是在运行时通过组合的方式将新功能附加到对象上。比如，在一个图形绘制系统中，通过装饰器模式可以给基本图形对象（如圆形、矩形）添加阴影、边框等装饰效果，增强其显示效果。
- 举例说明：假设我们有一个视频播放接口VideoPlayer，真实主题RealVideoPlayer实现了该接口，能够播放视频。如果使用代理模式，可能会创建一个ProxyVideoPlayer代理对象，用于控制对RealVideoPlayer的访问，比如检查用户是否购买了视频观看权限，只有有权限的用户才能调用真实播放器的播放方法。代码示例如下：
cpp
// 抽象主题：视频播放接口
class VideoPlayer {
public:
virtual void playVideo() = 0;
virtual ~VideoPlayer() {}
};
// 真实主题：真实视频播放器
class RealVideoPlayer : public VideoPlayer {
public:
void playVideo() override {
std::cout << "正在播放视频" << std::endl;
}
};
// 代理主题：代理视频播放器
class ProxyVideoPlayer : public VideoPlayer {
private:
RealVideoPlayer* realPlayer;
bool hasPermission;
public:
ProxyVideoPlayer() {
realPlayer = new RealVideoPlayer();
hasPermission = checkPermission();// 假设此方法用于检查权限
}
~ProxyVideoPlayer() {
delete realPlayer;
}
void playVideo() override {
if (hasPermission) {
realPlayer->playVideo();
}
else {
std::cout << "您没有观看权限" << std::endl;
}
}
bool checkPermission() {
// 实际实现权限检查逻辑
return true;
}
};如果使用装饰器模式，可能会创建一个DecoratedVideoPlayer装饰器对象，用于给RealVideoPlayer添加额外功能，比如添加播放记录功能，在播放视频前后记录播放时间等信息。代码示例如下：
cpp
// 抽象装饰器：视频播放器装饰器
class VideoPlayerDecorator : public VideoPlayer {
protected:
VideoPlayer* player;
public:
VideoPlayerDecorator(VideoPlayer* p) : player(p) {}
void playVideo() override {
player->playVideo();
}
};
// 具体装饰器：添加播放记录功能的装饰器
class RecordVideoPlayerDecorator : public VideoPlayerDecorator {
public:
RecordVideoPlayerDecorator(VideoPlayer* p) : VideoPlayerDecorator(p) {}
void playVideo() override {
std::cout << "开始记录播放时间" << std::endl;
player->playVideo();
std::cout << "结束记录播放时间" << std::endl;
}
};在实际应用中，如果需求是对对象的访问进行控制、管理，如权限验证、远程调用管理等，应选择代理模式；如果需求是在不改变对象接口的前提下，动态地为对象添加新的功能或增强现有功能，如添加日志记录、性能监控等，装饰器模式是更合适的选择。
3.2 代理模式的线程安全处理
在多线程环境下，代理模式可能会面临一些线程安全问题，主要包括以下几个方面：
- 代理对象状态不一致：当多个线程同时访问代理对象时，如果代理对象内部维护了一些状态信息，如缓存数据、连接状态等，可能会出现线程竞争，导致状态不一致。例如，一个缓存代理在多线程环境下，一个线程正在更新缓存数据，另一个线程同时读取缓存，可能会读到未更新完的数据。
- 并发访问真实对象 ：多个线程可能同时通过代理对象访问真实对象，如果真实对象的方法不是线程安全的，会导致数据不一致或其他错误。比如，一个数据库操作代理，多个线程同时通过代理执行数据库写入操作，可能会造成数据冲突。
为了解决这些线程安全问题，可以采取以下处理方法： - 加锁机制：在代理对象的关键方法中使用互斥锁（如std::mutex）来保证同一时间只有一个线程能够访问临界区代码。例如，在缓存代理的读取和更新缓存方法中加锁：
cpp
#include <mutex>
class CacheProxy {
private:
std::mutex cacheMutex;
std::map<std::string, std::string> cache;
public:
std::string getFromCache(const std::string& key) {
std::lock_guard<std::mutex> lock(cacheMutex);
auto it = cache.find(key);
if (it != cache.end()) {
return it->second;
}
return "";
}
void putToCache(const std::string& key, const std::string& value) {
std::lock_guard<std::mutex> lock(cacheMutex);
cache[key] = value;
}
};std::lock_guard会在构造时自动加锁，析构时自动解锁，确保在临界区代码执行期间，其他线程无法访问，避免了数据竞争。
- 使用线程安全的数据结构：选择线程安全的数据结构来存储代理对象的状态信息，如std::unordered_map在多线程环境下不是线程安全的，可以使用std::unordered_map结合锁来实现线程安全，或者直接使用线程安全的容器，如 C++ 17 引入的std::shared_mutex结合std::map实现的线程安全读写分离的缓存：
cpp
#include <shared_mutex>
#include <map>
class ThreadSafeCache {
private:
std::map<std::string, std::string> cache;
std::shared_mutex cacheMutex;
public:
std::string getFromCache(const std::string& key) {
std::shared_lock<std::shared_mutex> lock(cacheMutex);
auto it = cache.find(key);
if (it != cache.end()) {
return it->second;
}
return "";
}
void putToCache(const std::string& key, const std::string& value) {
std::unique_lock<std::shared_mutex> lock(cacheMutex);
cache[key] = value;
}
};std::shared_lock用于读操作，允许多个线程同时读取；std::unique_lock用于写操作，保证同一时间只有一个线程进行写入，从而实现了读写分离的线程安全。
- 使用线程局部存储（TLS）：对于一些与线程相关的状态信息，可以使用线程局部存储来存储，每个线程都有自己独立的副本，避免了线程间的竞争。例如，在代理对象中，如果需要记录每个线程的访问次数，可以使用线程局部存储：
cpp
#include <thread>
#include <mutex>
#include <iostream>
thread_local int accessCount = 0;
class Proxy {
public:
void access() {
accessCount++;
std::cout << "当前线程访问次数: " << accessCount << std::endl;
}
};每个线程访问Proxy对象的access方法时，accessCount是该线程独有的，不会受到其他线程的影响。
3.3 代理模式的性能优化
代理模式在实际应用中，可能会因为代理层的存在引入一些性能开销，如方法调用的额外开销、代理对象创建和销毁的开销等。为了提高代理模式的性能，可以采取以下优化策略：
- 缓存代理结果：对于一些频繁调用且结果不经常变化的方法，代理对象可以缓存方法的返回结果，避免每次都调用真实对象的方法，减少开销。例如，在一个查询数据库的代理中，可以缓存查询结果：
cpp
class DatabaseProxy {
private:
std::map<std::string, std::string> cache;
public:
std::string queryDatabase(const std::string& sql) {
auto it = cache.find(sql);
if (it != cache.end()) {
return it->second;
}
// 实际查询数据库的代码，假设为queryRealDatabase方法
std::string result = queryRealDatabase(sql);
cache[sql] = result;
return result;
}
std::string queryRealDatabase(const std::string& sql) {
// 实际数据库查询逻辑
return "查询结果";
}
};通过缓存查询结果，当相同的查询再次出现时，直接从缓存中返回结果，大大提高了查询效率。
- 优化代理对象创建过程：如果代理对象的创建开销较大，可以采用对象池技术，预先创建一定数量的代理对象，需要时从对象池中获取，使用完毕后再放回对象池，避免频繁创建和销毁代理对象。例如：
cpp
#include <vector>
#include <mutex>
class ProxyObject {
public:
void doSomething() {
std::cout << "执行代理对象的操作" << std::endl;
}
};
class ProxyObjectPool {
private:
std::vector<ProxyObject*> pool;
std::mutex poolMutex;
public:
ProxyObjectPool(int initialSize) {
for (int i = 0; i < initialSize; i++) {
pool.push_back(new ProxyObject());
}
}
~ProxyObjectPool() {
for (auto obj : pool) {
delete obj;
}
}
ProxyObject* getProxyObject() {
std::lock_guard<std::mutex> lock(poolMutex);
if (pool.empty()) {
return new ProxyObject();
}
ProxyObject* obj = pool.back();
pool.pop_back();
return obj;
}
void releaseProxyObject(ProxyObject* obj) {
std::lock_guard<std::mutex> lock(poolMutex);
pool.push_back(obj);
}
};通过对象池，减少了代理对象创建和销毁的开销，提高了性能。
- 减少代理层的不必要逻辑：仔细分析代理层的逻辑，去除一些不必要的操作，如重复的日志记录、多余的权限检查等，降低代理层的处理时间。例如，如果某些权限检查在真实对象中已经进行，代理层可以不再重复检查，避免双重检查带来的性能损耗。
四、实战项目：图片加载缓存系统（代理版）
4.1 项目需求
在很多应用中，图片加载是常见且重要的功能，如社交类应用展示用户头像、图片分享应用浏览图片等场景。而网络图片加载往往面临网络不稳定、加载速度慢等问题，同时频繁下载相同图片会浪费网络流量和时间。基于此，本图片加载缓存系统的需求如下：
- 加载网络图片：能够根据给定的图片 URL，从网络中获取图片数据并显示，这需要处理网络请求相关的操作，如创建 HTTP 连接、发送请求、接收响应数据等。
- 本地缓存：将加载过的图片存储在本地，当再次请求相同 URL 的图片时，优先从本地缓存中读取，减少网络请求。本地缓存需要考虑存储位置（如内存缓存、磁盘缓存）、缓存数据结构（如哈希表，以图片 URL 为键，图片数据为值）等问题。
- 避免重复下载：当多个地方同时请求相同 URL 的图片时，确保只进行一次网络下载，避免资源浪费。这就需要在缓存系统中增加相应的判断逻辑，在有下载请求时，先检查是否正在下载或已缓存该图片。
需求重点在于实现高效的图片加载和缓存机制，确保在不同网络环境下都能快速展示图片。难点则在于如何设计合理的缓存策略，如缓存淘汰策略（当缓存空间不足时，决定哪些图片数据需要被删除），以及如何保证缓存数据的一致性和线程安全性，在多线程环境下避免数据冲突。
4.2 代理模式实现图片加载缓存逻辑
下面是使用代理模式实现图片加载缓存逻辑的 C++ 代码示例：
cpp
#include <iostream>
#include <string>
#include <map>
#include <memory>
// 抽象主题：图片加载接口
class ImageLoader {
public:
virtual std::string loadImage(const std::string& url) = 0;
virtual ~ImageLoader() {}
};
// 真实主题：实际从网络加载图片的类
class RealImageLoader : public ImageLoader {
public:
std::string loadImage(const std::string& url) override {
// 模拟从网络加载图片的操作，这里直接返回一个固定字符串表示图片数据
std::cout << "从网络加载图片: " << url << std::endl;
return "图片数据来自网络: " + url;
}
};
// 代理主题：图片加载代理类，实现缓存功能
class ImageLoaderProxy : public ImageLoader {
private:
std::unique_ptr<RealImageLoader> realLoader;
std::map<std::string, std::string> cache;
public:
ImageLoaderProxy() : realLoader(std::make_unique<RealImageLoader>()) {}
std::string loadImage(const std::string& url) override {
auto it = cache.find(url);
if (it != cache.end()) {
std::cout << "从缓存加载图片: " << url << std::endl;
return it->second;
}
std::string imageData = realLoader->loadImage(url);
cache[url] = imageData;
return imageData;
}
};代码功能解释：
- 抽象主题（ImageLoader）：定义了一个纯虚函数loadImage，用于加载图片，返回值为图片数据（这里用std::string简单表示）。它是客户端与真实加载类、代理类交互的统一接口。
- 真实主题（RealImageLoader）：实现了ImageLoader接口，loadImage方法模拟从网络加载图片的操作，实际应用中这里应包含创建网络连接、发送 HTTP 请求、接收并处理图片数据等逻辑，这里简化为直接返回一个表示图片数据的字符串。
- 代理主题（ImageLoaderProxy）：同样实现ImageLoader接口，持有RealImageLoader的智能指针realLoader，并维护一个std::map作为缓存，键为图片 URL，值为图片数据。在loadImage方法中，首先检查缓存中是否已存在该 URL 对应的图片数据，如果存在则直接返回；若不存在，调用真实加载类的loadImage方法从网络加载图片，加载成功后将图片数据存入缓存，再返回数据。通过这种方式，实现了图片加载的缓存代理功能。
4.3 缓存命中率测试与性能优化
- 测试缓存命中率的方法 ：
可以通过编写测试用例来统计缓存命中率。例如，准备一组图片 URL，多次调用图片加载方法，记录从缓存中获取图片的次数和总的图片加载次数，缓存命中率 = 从缓存中获取图片的次数 / 总的图片加载次数。示例代码如下：
cpp
#include <vector>
int main() {
ImageLoaderProxy proxy;
std::vector<std::string> urls = {"url1", "url2", "url1", "url3", "url2"};
int totalCount = 0;
int cacheHitCount = 0;
for (const auto& url : urls) {
totalCount++;
auto it = proxy.cache.find(url);
if (it != proxy.cache.end()) {
cacheHitCount++;
}
proxy.loadImage(url);
}
double hitRate = static_cast<double>(cacheHitCount) / totalCount;
std::cout << "缓存命中率: " << hitRate * 100 << "%" << std::endl;
return 0;
}在上述代码中，通过遍历图片 URL 列表，每次加载图片前检查缓存中是否存在该图片，统计缓存命中次数和总加载次数，从而计算出缓存命中率。
- 性能瓶颈分析与优化建议 ：
- 缓存空间限制：如果缓存空间无限增大，会消耗大量内存。可以采用缓存淘汰策略，如 LRU（最近最少使用）算法，当缓存达到一定容量时，淘汰最近最少使用的图片数据。可以使用std::list和std::unordered_map结合实现 LRU 缓存，std::list用于存储图片 URL 的访问顺序，std::unordered_map用于快速查找图片 URL 在std::list中的位置。
- 缓存更新策略：当图片在服务器端更新后，本地缓存中的图片可能不是最新的。可以设置缓存过期时间，或者在加载图片时，通过 HTTP 头信息（如Last-Modified、ETag）判断图片是否更新，若更新则重新下载并更新缓存。
- 多线程访问：在多线程环境下，缓存的读写操作可能存在线程安全问题。可以使用互斥锁（如std::mutex）对缓存的读写操作进行加锁保护，或者使用线程安全的缓存数据结构，如前面提到的std::shared_mutex结合std::map实现的线程安全读写分离的缓存。