Using heap viewer, we can see that after the first GC, only 1.39 megs is free.
This may indicate that the garbage collector wasn't able to reclaim much
memory due to a leak.
After a second GC event, heap viewer indicates that the system has decided to
accommodate a larger memory footprint for this app by allocating more memory.
Increasing the heap size to 32 megabytes,
which is up from 20 megabytes in the first GC.
This time, we have 12.9 megabytes free in our heap.
At this point, the system is dynamically accommodating for
the larger memory footprint of this app.
If the expansion repeats, this may lead to an app crash if the system can no
longer allocate more memory for the app.
So remember, memory leaks are slow and they're insidious and require time and
the proper test environment to confirm.
Also, keep in mind that sometimes a pattern like this
might represent a legitimate use of memory.
For example,
imagine an application that was designed to manipulate large graphics or photos.
The takeaway here is be on the lookout for slow leaking memory, but
always weigh the data you collect,
against the memory implications of your app's core functionality.
Now at this point, you should understand how memory leaks manifest in the SD.
At this point, you should understand how memory leaks manifest in SDK provided
tools such as Memory Monitor and Heap Viewer.
But you might not know where they originate.
Here are some best practices you can take to avoid a leak.
Track the life of your objects throughout your code and
clean up references when you no longer need them.
Okay, so in the next slide,
we'll identify what might be causing this leak.
بعد عارض الذاكرة التكويمية GC الأولى، يوجد فقط 1.39 ميجا فارغة.
قد يشير هذا إلى أن جامع البيانات عديمة النفع لم يستطع استعادة كثير
من الذاكرة بسبب التسريب.
بعد حدث GC الثاني، يشير العارض التكويمي إلى أن النظام قد قرر
استيعاب أكبر للذاكرة في التطبيق عن طريق تخصيص مزيد من الذاكرة.
زيادة الذاكرة التكويمية إلى حجم 32 ميجا بايت،
وهو ما يصل من 20 ميغابايت في جمع البيانات عديمة النفع الأول.
في هذا الوقت لدينا 12.9 ميجابايت فارغة في الذاكرة التكويمية لدينا
عند هذه النقطة، فإن هذا النظام يستوعب ديناميكياً
أكبر قدر من الذاكرة في هذا التطبيق.
إذا تكرر التوسع، قد يؤدي إلى توقف التطبيق إذا كان النظام لا يمكنه
تخصيص المزيد من الذاكرة للتطبيق.
لذلك تذكر، يعتبر تسرب الذاكرة بطيء بشكل خبيث ويستغرق وقتا
وبيئة الاختبار المناسبة للتأكيد على ذلك.
أيضا، ضع في الاعتبار أن أحيانا نمطا من هذا القبيل
قد يمثل الاستخدام المسموح به للذاكرة.
على سبيل المثال،
تخيل التطبيق المصمم لمعالجة . الرسومات الكبيرة أو الصور
الاستبعاد هنا يكون عند رصد التسرب البطيء للذاكرة، ولكن
دائما تأمل البيانات التي تجمعها،
في مقابل نتائج وآثار الذاكرة على الوظائف الأساسية لتطبيقك.
في هذه المرحلة، ينبغي أن تفهم كيف تتسرب الذاكرة بوضوح في SD.
عند هذه النقطة، يجب أن تفهم كيف تتسرب الذاكرة بوضوح في SDK في
الأدوات المقدمة مثل مراقب الذاكرة وعارض الذاكرة التكويمية.
لكنك قد لا تعرف من أين بدأت.
فيما يلي بعض أفضل الممارسات التي يمكنك اتخاذها لتجنب التسرب.
تتبع حياة أشيائك أثناء كتابة الكود
مع تنظيف المراجع عندما لم تعد في حاجة إليها.
حسنا، في الشريحة التالية،
سوف نحدد ما الذي يمكن ان يكون السبب في هذا التسرب.
Utilizando Heap Viewer, vemos que tras el primer CG, sólo quedan 1,39 megas libres.
Esto puede indicar que el recolector de basura no recuperó
mucha memoria, debido a una fuga.
Tras el segundo evento GC, Heap Viewer indica que el sistema decidió
alojar un mayor uso de memoria para ésta app, asignando más memoria.
Aumentando el tamaño de la pila hasta 32 megabytes,
que son más de los 20 megabytes en el primer GC.
Ésta vez, tenemos 12,9 megabytes libres en nuestra pila
Aquí, el sistema se está adaptando dinámicamente
al mayor consumo de memoria de ésta app.
Si la expansión se repite, pudiera hacer fallar la app, si el sistema ya no
pudiera asignar más memoria para la app.
Recuerda, las fugas de memoria son lentas e insidiosas, y requieren tiempo
y el ambiente de prueba adecuado para ser confirmadas.
También ten en cuenta que, a veces, un patrón como éste
puede representar una utilización legítima de memoria.
Por ejemplo,
Imagina una aplicación diseñada para manipular imágenes grandes o fotos.
La moraleja aquí es estar atento a fugas lentas de memoria, pero
siempre ponderar los datos reunidos
contra las implicaciones de memoria en la funcionalidad principal de tu app.
Ahora ya deberías entender cómo se manifiestan las fugas de memoria en la SD.
Ahora ya entenderás como se manifiestan las fugas de memoria en SDK
usando herramientas como Memory Monitor y Heap Viewer.
Pero tal vez no sepas dónde se originan.
Aquí verás algunas mejores prácticas que adoptar para evitar fugas.
Rastrea la vida de tus objetos a través de tu código
y limpia las referencias cuando ya no las necesites.
En la próxima diapositiva,
identificaremos qué pudiera estar causando ésta fuga.
Avec Heap Viewer, nous voyons qu'après le1er GC, seulement 1,39 Mo est libéré.
Cela peut indiquer que le garbage collector ne pouvait en récupérer plus
à cause de la fuite.
Après un 2è événement GC, Heap Viewer indique que le système a décidé de
d'avoir plus d'empreinte mémoire pour cette app en allouant plus de mémoire.
Augmentant la taille du tas de 32 mégaoctets,
une hausse de 20 mégaoctets par rapport au 1er GC.
Cette fois, nous avons 12,9 mégaoctets de libre dans notre tas.
A ce point, le système s'adapte dynamiquement à la grande
mémoire d'empreinte de cette application.
Si l'expansion se répète, on peut avoir un plantage de l'app si le système ne peut
plus allouer plus de mémoire pour l'app.
Alors rappelez-vous, les fuites de mémoire sont lentes et insidieuses et exigent
du temps et le bon environnement de test pour confirmer.
Aussi, retenez que parfois un modèle comme ça
pourrait représenter une utilisation légitime de la mémoire.
Par exemple,
imaginer une application conçue pour manipuler de grands graphiques ou photos.
Le truc ici est d'être à l'affût d'une fuite lente de mémoire, mais
toujours évaluer les données que vous collectez,
par rapport à la mémoire pour la fonctionnalité de base de votre app.
Maintenant, vous devez comprendre comment les fuites de mémoire apparaissent dans SD.
Aussi, vous devez comprendre comment elles se manifestent dans les outils SDK
comme Memory Monitor et Heap Viewer
Mais vous ne sauriez peut-être pas d'où elles viennent
Voici quelques pratiques à faire pour éviter une fuite.
Suivre la vie de vos objets à travers votre code et
nettoyer les références lorsque vous en avez plus besoin.
Bien, alors dans la prochaine vidéo,
nous allons identifier ce qui pourrait être à l'origine de cette fuite.
Menggunakan Heap Viewer, kita dapat melihat setelah GC pertama
hanya 1,39 megabit yang bebas.
Ini mungkin menunjukkan kolektor sampah tidak mampu merebut banyak
memori karena kebocoran.
Setelah GC kedua, Heap Viewer menunjukkan bahwa sistem memutuskan untuk
menampung jejak memori yang lebih besar untuk aplikasi ini
dengan alokasikan lebih banyak memori.
Meningkatkan ukuran tumpukan ke 32 megabit,
Yang naik dari 20 megabit di GC pertama.
Kali ini, kita memiliki 12,9 megabit bebas dalam tumpukan kami.
Pada titik ini, sistem secara dinamis mengakomodatif untuk
jejak memori yang lebih besar dari aplikasi ini.
Jika ekspansi terulang, ini dapat mengakibatkan aplikasi Crash
dan sistem tak lagi bisa mengalokasikan lebih banyak memori untuk aplikasi.
Jadi ingat, kebocoran memori itu lambat dan mereka berbahaya
dan membutuhkan waktu dan lingkungan pengujian yang tepat untuk konfirmasi.
Perlu diingat bahwa terkadang pola seperti ini
mungkin mewakili penggunaan yang sah dari memori.
Misalnya,
bayangkan sebuah aplikasi yang dirancang untuk memanipulasi grafis besar atau foto.
Yang menarik di sini adalah waspadalah untuk memori bocor yang lambat,
tapi selalu menimbang data yang Anda kumpulkan,
terhadap implikasi memori dari fungsi inti aplikasi Anda.
Sekarang Anda seharusnya sudah paham bagaimana kebocoran memori terjadi di SD.
Pada titik ini, Anda seharusnya paham
bagaimana kebocoran terjadi dan SDK menyediakan alat
seperti Memory Monitor dan Heap Viewer.
Tapi Anda mungkin tak tahu dari mana mereka berasal.
Berikut ini beberapa praktik terbaik untuk menghindari kebocoran.
Melacak kehidupan seluruh kode objek Anda
dan membersihkan referensi saat Anda tidak lagi membutuhkannya.
Oke, di tampilan berikutnya,
kita akan mengidentifikasi sebab kebocoran ini.
ヒープビュアを利用すると初GC後に 1.39MBを無料で確認できます
ここでGCはきちんと 調整を行えないかもしれません
メモリリークがあるからです
2番目のGCイベントはヒープビュアが システムを決定したことを意味します
より大きなメモリのレコードを見たアプリに より多くのメモリを割当しようとします
ヒープのサイズは32MBに増加して
初GCを行った20MBから 引き上げたのです
今は12.9MBがヒープ内で フリーな状態です
この時点でシステムは 積極的に受け入れています
アプリのより大きい メモリレコードのためです
拡張が繰り返される場合 アプリは衝突を起こすでしょう
システムはアプリのための割当を それ以上行いません
そのため メモリリークが密かに ゆっくり進んむと時間とmfが必要です
適切なテスト環境を確認しましょう
このようなパターンを見たら 覚えておいてください
メモリを正常的に使用していることを 表示する場合もあります
例えば
アプリの画像はサイズの大きいグラフィック または写真としてデザインされる時があります
ゆっくりとリークするメモリへの 表面上の対策は
アプリの重要機能は 常に
あなたが集めたデータの大きさで メモリの影響に対応します
この時点でSD上のメモリが どういうふうにリークしているかを
提供されたSDKを見て 理解してください
メモリモニターやヒープビュアのような ツールを使ってです
ですが あなたはそれがどこから 来ているか分からないかもしれません
メモリリークを避ける 最善の方法を紹介します
コードからオブジェクトの寿命を 追跡して
もういらないと判断した時に 参照を片付けます
はい 次のスライドは
リークが行われる時 何が問題か識別しましょう
Heap Viewer로 보면 첫 GC는 1.39MB밖에 확보하지 못했습니다
이건 메모리 누수 때문에
GC가 많은 메모리를 반납하지 못한 가능성을 암시하는데요
두 번째 GC 이벤트 이후 시스템이 애플리케이션에게
추가적으로 메모리를 할당한 게 Heap Viewer를 통해 보입니다
힙 크기가 32MB로 늘었습니다
첫 GC 당시의 20MB 보다 커졌어요
이제 저희 힙에 가용 메모리가 12.9MB만큼 있어요
시스템은 애플리케이션의 메모리 사용량에 반응해
동적으로 메모리 할당량을 늘린 거예요
이 패턴이 반복되어 시스템이 더 이상 애플리케이션에게
메모리를 할당해주지 못하면 애플리케이션은 크래시 됩니다
그러니 기억하세요, 메모리 누수는 서서히 일어나기 때문에
발견하기 위해선 충분한 시간과 적절한 시험 환경이 필요해요
그리고 메모리 할당을 올바르게 해도
이런 패턴이 발생할 수 있다는 점도 잊지 마세요
예를 들어
큰 용량의 삽화나 사진을 조작하는 애플리케이션을 상상해보세요
여기서 교훈은 서서히 누수되는 메모리를 경계하되
수집한 자료와 애플리케이션 핵심 기능의 메모리 사용 방법을 비교해
메모리 누수 여부를 판단하셔야 한다는 겁니다
이제 여러분은 Memory Monitor와 Heap Viewer 같은
SDK에서 제공하는 툴을 사용해
메모리 누수를 찾는 방법을 이해하셨을 거예요
하지만 메모리 누수가 어디서 시작되었는지 모를 수도 있겠네요
그러니 메모리 누수를 방지하는 요령을 알려드릴게요
코드에서 생성하는 객체의 수명을 파악해
더 이상 참조할 필요가 없으면 제거해주세요
좋아요, 그럼 다음 슬라이드에선
이 메모리 누수의 원인을 파헤쳐 볼게요
Usando o visualizador de heap, vemos que depois do GC, só há 1,30 mega livre.
Isso pode indicar que o Coletor de lixo não conseguiu recuperar
muita memória devido a um buraco.
Depois do segundo GC, visualizador de heap indicou que o sistema decidiu
armazenar uma memória maior para esse aplicativo atribuindo mais memória.
Aumentando o tamanho do heap para 32 megas,
que era 20 megas no primeiro GC.
Agora, temos 12.9 megas livres no heap.
Agora, o sistema está acomodando dinamicamente
para um espaço de memória maior desse aplicativo.
Se a expansão se repetir, pode travar o aplicativo se o sistema
não disponibilizar mais memória para o aplicativo.
Lembre-se, as perdas de memória são lentas e traiçoeiras
e requerem teste apropriado do ambiente para confirmação.
Tenha em mente que algumas vezes um padrão como esse
pode representar um uso legítimo da memória.
Por exemplo,
imagine um aplicativo feito para manipular muitos gráficos ou fotos.
A chave aqui é analisar a memória de vazamento lento
sempre medir sua coleta de dados,
diante dos resultados de memória da funcionalidade do aplicativo.
Agora, você já deve entender como o vazamento da memória se dá no SD.
Já deve entender como o vazamento da memória se manifesta nas
ferramentas SDK como o Monitor de Memória e o Visualizador de Heap.
Mas você talvez não saiba da onde eles vem.
Essas são algumas das práticas que você pode adotar para evitar o vazamento.
Procure a existência dos objetos por todo o código e
apague as referências que você não precisa mais.
Certo, então no próximo slide,
vamos identificar o que pode causar esse vazamento.
Heap Viewer показывает, что после первого СМ было освобождено только 1,39 МБ памяти.
Это может служить индикатором того, что сборщик мусора не смог вернуть
достаточно памяти из-за утечки.
После второго события СМ, Heap Viewer показывает, что система приняла решение
выделить больше памяти этому приложению,
тем самым повышая доступный объём динамической памяти до 32 мегабайт,
что выше тех 20 мегабайт, которые имелись в момент первого запуска СМ.
Теперь у нас имеется 12,9 мегабайт свободной памяти.
В данный момент система динамически распределяет
более высокий объём памяти для приложения.
Если рост повторяется, это может привести к падению приложения, если система
больше не сможет выделять память.
Итак, запомните, утечки памяти могут быть медленными и хитрыми и требовать времени и
правильной среды для их нахождения.
Также помните, что иногда подобное поведение
может означать, что память используется нормальным образом.
Например,
представим приложение, которое служит для обработки больших схем или фотографий.
Здесь важно следить за медленно утекающей памятью,
однако всегда оценивайте собранные данные
с точки зрения задействования памяти в основной работе вашего приложения.
Сейчас вы должны понимать, как утечки памяти проявляются в SDK.
Сейчас вы должны понимать, как утечки памяти проявляются в SDK
при помощи таких инструментов, как Memory Monitor и Heap Viewer.
Однако, вы можете не знать, откуда они появились.
Вот несколько советов, как избежать утечек.
Следите за жизненным циклом объектов по всей программе,
и удаляйте ссылки, когда они больше не используются.
А на следующем слайде
мы определим, что могло вызвать утечку.
Yığın izleyici kullanarak, ilk GC'den sonra yalnızca 1.39 milyonun boş olduğunu
görüyoruz. Bu, çöp toplayıcısının sızıntıdan dolayı çok fazla
hafızayı iyileştirediğini gösterebilir. İkinci bir GC olayından sonra,
yığın izleyici sistemin, bu uygulama için daha fazla hafızayı bölerek
daha geniş bellek parmak izi düzenlemesine karar verdiğini göstermektedir.
Yığın boyutunu 32 megabyte'a çıkartarak, ki
20 megabyte'dan ilk GV'de daha yukarıdadır.
Bu sefer yığınımızda 12.9 megabyte'ımız var.
Bu noktada, sistem dramatik olarak bu uygulamanın
daha geniş kapladığı alan için bunu denkleştirir.
Genişleme tekrar ederse, bu uygulama kazasına neden olabilir, eğer sistem
artık daha fazla uygulama için hafıza dağıtamazsa.
O zaman unutmayın, hafıza sızıntısı yavaş olur ve bunlar sinsidir ve
onaylamak için düzgün test ortamı gerektirir ve bu zaman alır.
Aynı zamanda, bunun gibi bir modelin hafızanın meşru kullanımını
temsil edebileceğini unutmayın.
Örneğin, geniş grafikler veya fotoğrafları çalıştırmak
için dizayn edilmiş bir uygulamanın olduğunu farzedin.
Paketleme servisi burada yavaş hafıza sızıntısı için tetikte beklemektedir ancak
daima uygulamanızın çekirdek işlevliğinin hafıza
sonuçlarına karşı topladığınız verileri tartmaktadır.
Bu noktada, SD'de hafızanın manifestoya nasıl sızdığını anlayabilirsiniz.
Bu noktada, Hafıza Monitörü ve Yığın İzleyicisi gibi sağlanmış
olan araçların hafızanın SDK manifestosuna nasıl sızdığını anlamanız gerekir.
Ancak nereden kaynaklandığını bilemeyebilirsiniz.
Sızıntıdan kaçınmak için işte size bazı iyi çalışma yöntemleri.
Kodunuz boyunca objelerinizin hayatını takip edin ve ihtiyacınız olmadığında
kaynakları (referansları) temizleyin.
Tamam, bir sonraki slayt gösteriminde bu sızıntıya
neyin neden olabileceğiniz tanımlayacağız.
Với heap viewer, chúng ta có thể thấy sau GC đầu tiên, chỉ có 1,39 megs còn trống.
Điều này có thể cho thấy bộ garbage collector đã không thể dành lại
nhiều bộ nhớ do một lỗ hổng.
Sau sự kiện GC thứ hai, Heap Viewer chỉ ra rằng hệ thống đã quyết định
cấp lượng bộ nhớ lớn hơn cho ứng dụng này bằng cách phân bổ thêm bộ nhớ.
Tăng kích thước vùng lên 32 megabyte,
từ 20 megabyte trong GC đầu tiên.
Lần này, chúng ta còn 12,9 megabyte trống trong vùng.
Đến lúc này, hệ thống đã tự động cấp
bộ nhớ lớn hơn cho ứng dụng này.
Nếu việc mở rộng lặp lại, nó có thể khiến ứng dụng sụp đổ
nếu hệ thống không thể cấp thêm bộ nhớ cho ứng dụng này nữa.
Vì vậy, hãy nhớ, lỗ hổng bộ nhớ rất chậm chạp và ngấm ngầm,
nó cần thời gian và điều kiện thử nghiệm đúng chuẩn mới có thể xác định.
Ngoài ra, hãy nhớ rằng đôi khi một mô hình như thế này
cũng có thể đại diện cho việc sử dụng bộ nhớ hợp lệ.
Ví dụ như,
hãy tưởng tượng ứng dụng được thiết kế để thao tác các đồ họa hoặc hình ảnh lớn.
Việc sử dụng ở đây nhìn trực giác giống như bộ nhớ đang bị rò rỉ chậm, nhưng hãy
luôn cân nhắc những dữ liệu bạn thu được
với những biểu hiện của bộ nhớ về chức năng cốt lõi của ứng dụng đó.
Bây giờ tại điểm này, bạn sẽ hiểu được cách mà lỗ hổng bộ nhớ thể hiển trong SD.
Tại điểm này, bạn sẽ hiểu được cách lỗ hổng bộ nhớ thể hiện
trong các công cụ SDK như Memory Monitor hay Heap Viewer.
Nhưng bạn có thể không biết nguồn gốc của chúng.
Dưới đây là một số việc tốt nhất bạn có thể làm để tránh lỗ hổng.
Theo dõi sự tồn tại của các đối tượng thông qua mã của bạn
dọn dẹp các tham chiếu khi bạn không cần đến chúng nữa.
Ok, và trong slide tiếp theo,
ta sẽ xác định điều gì có thể tạo những lỗ hổng này.
通过heap viewer，可知第一次GC仅释放了1.39兆内存。
这种结果显示，因为漏洞的存在，
垃圾清理无法回收全剖垃圾。
Heap viewer显示第二次GC后，
系统必须经由配置更多的内存，来调整内存量。
堆从第一次GC的20兆，
增加到32兆。
此次Java堆释放了12.9兆。
这时，
系统不断地为程序配置更多的内存。
以上动作如果一再重复，系统终会无法配置内存。
程序也就挂了。
切记，内存漏洞非常缓慢又不易被发现，
需要时间，跟适当的环境来确认，
有时，这样的数据，
也表示内存的正当存取。
比如
处理图片跟照片的程序，
表面看似内存在泄漏，
实际上它针对核心功能的存储器，
不停地进行数据评估。
因此，要明白内存漏洞如何显示在SD上。
也要清楚，内存漏洞如何显示在拥有SDK的工具上。
如Memory Monitor和Heap Viewer。
但是，各位可能不知道他们源于何地，
以下这些方法，可以防止漏洞的出现。
利用编码查看程序的寿命，
清理不用的文件。
接下来，
辨别漏洞产生的原因。
透過heap viewer可知第一次GC僅釋放1.39兆內存
這種結果顯示因為漏洞的存在
碎片帳集無法回收全部的垃圾
Heap Viewer顯示第二次GC後
系統必須經由配置更多的內存來調整內存量
堆從第一次GC的20兆
增加到32兆
此次Java堆釋放 了12.9兆
此時
系統不斷地為程式配置更多的內存
此動作如果一再地重復 系統最終無法配置內存
程式也就當掉了
切記內存漏洞非常緩慢且不易被查覺
需要時間跟適當的環境來確定
有時這樣的數據
也表示內存的正當存取
如
處理圖像跟照片的程式
表面看似內存在泄漏
實質上牠針對核心功能的存儲器
不時地進行數據評估
因此要明白內存漏洞如何呈現在SD上
也要明白內存漏洞如何呈現在擁有SDK的工具上
如Memory Monitor和 Heap Viewer
但大家可能不知道他們源於何處
以下這些方式可以防止漏洞的出現
利用編碼查看程式的壽命
清理無用的資料
接下來
辨識漏洞產生的原因