Un slice en Go no es una colección de datos por sí misma; es un descriptor (una estructura interna que contiene un puntero al backing array, un len y un cap). Cuando realizas un slicing como b := a[1:3], no estás duplicando la información, sino creando una nueva “ventana” que apunta a la misma región de memoria física. Esto se diseñó así para que el paso de sub-segmentos de datos sea una operación de tiempo constante $O(1)$ sin necesidad de copiar bytes innecesarios.
Sin embargo, esta eficiencia tiene un coste: el acoplamiento de memoria. Si modificas un elemento en b, estarás alterando el contenido de a porque ambos comparten el mismo array subyacente. Este comportamiento es vital para el rendimiento, pero puede derivar en dos problemas críticos: la corrupción de datos accidentales mediante append y fugas de memoria (memory leaks).
Si realizas un append sobre un slice que tiene capacidad excedente (es decir, cap > len), Go no reservará un nuevo array; simplemente escribirá el nuevo elemento en el siguiente espacio disponible del backing array compartido. Si ese espacio pertenecía a otro slice que tú creías que era independiente, habrás corrompido sus datos sin previo aviso. Para evitar esto cuando necesitas aislamiento total, la solución es usar la función copy() para volcar los datos en un nuevo array, o utilizar la expresión de slice completa a[low:high:max] para truncar la capacidad y forzar una reasignación en el próximo append.
package main
import (
"fmt"
)
func main() {
// 1. El efecto colateral de la modificación directa
base := []int{1, 2, 3, 4, 5, 6}
sub := base[1:4] // len=3, cap=5 (apunta de base[1] a base[5])
sub[0] = 99
fmt.Printf("Base modificada por sub: %v\n", base) // [1 99 3 4 5 6]
// 2. La trampa del append: corrupción de memoria compartida
// 'sub' tiene cap=5, por lo que append no disparará una nueva asignación
sub = append(sub, 88)
fmt.Printf("Base tras append en sub: %v\n", base) // [1 99 3 4 88 6] -> ¡Modificamos base[4]!
// 3. La solución: Full Slice Expression [low:high:max]
// Al definir el tercer parámetro (max), limitamos la capacidad (cap = max - low)
subSegura := base[1:4:4] // len=3, cap=3 (el limite es base[4])
subSegura = append(subSegura, 77)
fmt.Printf("SubSegura (nueva asignación): %v\n", subSegura)
fmt.Printf("Base permanece intacta: %v\n", base)
// 4. La solución definitiva: copy()
// Úsalo cuando necesites un slice que sea totalmente independiente de la vida del original
independiente := make([]int, len(base))
copy(independiente, base)
independiente[0] = -1
fmt.Printf("Independiente: %v | Base: %v\n", independiente, base)
}
Desglose del comportamiento
En el primer escenario, sub := base[1:4] crea un descriptor con len=3 y cap=5. El puntero de sub apunta a la dirección de memoria de base[1]. Por eso, al ejecutar sub[0] = 99, estamos escribiendo directamente en la dirección de base[1].
El error más sutil ocurre en el segundo caso. Como sub tenía capacidad para albergar un elemento más (cap=5 y len=3), el append simplemente escribió el 88 en la posición sub[3]. Si rastreamas la memoria, sub[3] es exactamente base[4]. Esto es un bug clásico en sistemas concurrentes o APIs donde se pasan slices que no deberían mutar la fuente original.
La expresión base[1:4:4] es una herramienta de diseño fundamental. Al establecer el tercer índice (max), forzamos a que la capacidad del slice sea igual a su longitud (cap = 4 - 1 = 3). Esto “encierra” al slice; si intentas hacer un append que exceda su len, el runtime de Go detectará que ya no hay capacidad y se verá obligado a realizar una nueva asignación de memoria, dejando el array original a salvo.
Por último, copy() es la opción más segura cuando la persistencia del sub-slice es incierta. Mientras que copy() crea un nuevo backing array, la función make + copy garantiza que no haya vínculos de memoria entre el origen y el destino.
El error frecuente
Un error común que causa fugas de memoria en servicios de alta carga es devolver un sub-slice de un buffer masivo.
func getSmallPart() []byte {
// Imaginemos un buffer de 100MB leído de un archivo
bigBuffer := make([]byte, 100*1024*1024)
// ... proceso de lectura ...
// Queremos solo los primeros 10 bytes
return bigBuffer[:10]
}
Aunque solo devuelvas 10 bytes, el objeto slice resultante mantiene un puntero al array de 100MB. El Garbage Collector no puede liberar esos 100MB mientras ese pequeño slice sea alcanzable, ya que el backing array es la unidad mínima de liberación de memoria. Para solucionarlo, siempre usa copy() si el sub-slice va a persistir más allá de la función que lo creó.
N° 49