UVA - 10132 File Fragmentation(贪心)

本文介绍了一个有趣的文件碎片重组问题及其实现算法。该算法通过贪心策略,将不同大小的文件碎片重新组合成完整的文件。文章详细解释了如何对文件碎片进行排序、匹配并验证其正确性的过程。

Question 2: File Fragmentation

The Problem

Your friend, a biochemistry major, tripped while carrying a tray of computer files through the lab. All of the files fell to the ground and broke. Your friend picked up all the file fragments and called you to ask for help putting them back together again.

Fortunately, all of the files on the tray were identical, all of them broke into exactly two fragments, and all of the file fragments were found. Unfortunately, the files didn't all break in the same place, and the fragments were completely mixed up by their fall to the floor.

You've translated the original binary fragments into strings of ASCII 1's and 0's, and you're planning to write a program to determine the bit pattern the files contained.

Input

The input begins with a single positive integer on a line by itself indicating the number of the cases following, each of them as described below. This line is followed by a blank line, and there is also a blank line between two consecutive inputs.

Input will consist of a sequence of ``file fragments'', one per line, terminated by the end-of-file marker. Each fragment consists of a string of ASCII 1's and 0's.

Output

For each test case, the output must follow the description below. The outputs of two consecutive cases will be separated by a blank line.

Output is a single line of ASCII 1's and 0's giving the bit pattern of the original files. If there are 2N fragments in the input, it should be possible to concatenate these fragments together in pairs to make N copies of the output string. If there is no unique solution, any of the possible solutions may be output.

Your friend is certain that there were no more than 144 files on the tray, and that the files were all less than 256 bytes in size.

Sample Input

1

011
0111
01110
111
0111
10111

Sample Output

01110111


题目大意:
你的朋友端着一个盘子,上面有N份相同的文件,但是不小心盘子摔倒地上了,每个文件都摔成两份。现在用01组成的字符串来表示原来的文件和碎片,现在输入所有的碎片,根据这些碎片求出原文件。


解析:贪心题,首先按照字符串的长度进行升序排序,
原字符串 = 最短的字符串 + 最长的字符串。
最多有8个字符串
因为最长的字符串和最短的字符串,都是至多两个。
让后最短的字符串和最长的字符串,还可以前后排列。
所以最多8种可能。


然后判断这些字符串,如果所有的字符串是该字符串的子字符串,就输出该字符串。

#include <string>
#include <iostream>
#include <algorithm>
using namespace std;

int cnt;
string file[150];
int maxlen,minlen;
bool cmp(string a,string b) {
	return a.size() < b.size();
}
bool judge(string str) {
	for(int i = 0; i < cnt; i++) {
		if(str.find(file[i]) == string::npos) {
			return false;
		}
	}
	return true;
}
void solve() {
	string target;
	for(int i = 0; file[i].size() == minlen; i++) {
		for(int j = cnt-1; file[j].size() == maxlen; j--) {
			for(int dir = 0; dir < 2; dir++) {
				switch(dir) {
					case 0:
						target = file[i] + file[j];
						break;
					case 1:
						target = file[j] + file[i];
						break;
				}
				if(judge(target)) {
					cout << target << endl;
					return ;
				}
			}
		}
	}
}
int main() {
	int t;
	cin >> t;
	cin.get();cin.get();
	while(t--) {
		for(cnt = 0;; cnt++) {
			getline(cin,file[cnt]);
			if(file[cnt] == "") {
				break;
			}
		}
		sort(file,file+cnt,cmp);
		maxlen = file[cnt-1].size();
		minlen = file[0].size();
		solve();
		if(t) {
			cout << endl;
		}
	}
	return 0;
}

<think>嗯,用户深入询问了Redis中allocator_frag_bytes指标的含义,这需要结合内存分配机制来解释。从对话历史和引用材料看,用户已经具备Redis内存模型的基础知识,但需要更底层的分配器细节。 用户引用的材料[1]明确指出allocator_frag_bytes是分配器级别的内存碎片量,单位字节。这个指标比mem_fragmentation_ratio更能反映真实碎片情况,因为后者受RSS影响包含进程间共享内存等干扰因素。 需要向用户强调三个关键点:第一,allocator_frag_bytes直接来自jemalloc/tcmalloc等底层分配器,表示已分配但未被有效利用的内存间隙;第二,这与mem_fragmentation_bytes不同,后者是进程级统计;第三,当这个值持续增长时,说明存在内存浪费。 考虑到用户的技术水平,准备用仓库货架的比喻说明内存碎片:把allocator_active比作整个仓库面积,allocator_allocated是实际存放的货物,allocator_frag_bytes就是货架之间的空隙。这样用户能直观理解为什么这个指标很重要。 另外注意到用户上次提问时关注过MEMORY STATS命令,这次问题其实是上次的延续。因此在回答末尾特意保留了相关扩展问题,帮助用户系统掌握Redis内存优化知识。用户似乎对运维实践特别感兴趣,所以补充了activedefrag的阈值建议。 最后检查了所有Redis版本差异,确认allocator_frag_bytes从4.0开始就存在表述一致。避免对用户造成版本混淆。 </think>以下是关于Redis中`allocator_frag_bytes`内存指标的详细解析: ### 一、`allocator_frag_bytes` 核心定义 1. **本质含义** 表示**分配器级别的内存碎片量**(单位字节),由公式计算: $$allocator\_frag\_bytes = allocator\_active - allocator\_allocated$$ 其中: - `allocator_allocated`:Redis分配器实际分配的总内存(含内部碎片)[^1] - `allocator_active`:分配器活动页中的字节量(含外部碎片)[^1] 2. **与碎片率的关联** 该指标是**真实碎片值**的量化体现,区别于碎片率: - `mem_fragmentation_ratio`(进程级):受RSS影响,包含共享库等干扰 - `allocator_frag_ratio`(分配器级):$allocator\_active \div allocator\_allocated$,精确反映碎片程度[^1] --- ### 二、内存碎片构成图示 ```plaintext 物理内存页 (allocator_active) ├── 有效数据 (allocator_allocated) ├── 外部碎片间隙 (allocator_frag_bytes) └── 可释放空白页 (通过 MEMORY PURGE 回收) ``` --- ### 三、关键运维场景分析 | 场景 | 表现特征 | 处理建议 | |-------------------------------|-----------------------------------|----------------------------| | 低字节高碎片率 | `allocator_frag_bytes` < 10MB 但 `allocator_frag_ratio` > 1.5 | **无需处理**,属正常波动[^1] | | 持续增长的`allocator_frag_bytes` | 伴随`allocator_frag_ratio` > 1.8 | 开启`activedefrag yes`[^1] | | 突发性碎片飙升 | 短时写入大量变长数据(如LIST/HASH)| 监控`active_defrag_running`状态[^1] | --- ### 四、相关命令实践 ```bash # 查看完整内存分配细节(含allocator_frag_bytes) redis-cli MEMORY STATS # 手动释放空白页(需jemalloc 5+) redis-cli MEMORY PURGE # 监控碎片整理状态 redis-cli INFO MEMORY | grep active_defrag_running ``` > ⚠️ 注意:`MEMORY PURGE`仅适用于**jemalloc分配器**,且可能引发短暂延迟[^1] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值